From report at bugs.python.org Thu Aug 1 00:12:00 2019 From: report at bugs.python.org (Windson Yang) Date: Thu, 01 Aug 2019 04:12:00 +0000 Subject: [issue29750] smtplib doesn't handle unicode passwords In-Reply-To: <1488919224.48.0.0966376973087.issue29750@psf.upfronthosting.co.za> Message-ID: <1564632720.5.0.130516045383.issue29750@roundup.psfhosted.org> Change by Windson Yang : ---------- pull_requests: +14813 pull_request: https://github.com/python/cpython/pull/15064 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 00:14:29 2019 From: report at bugs.python.org (Windson Yang) Date: Thu, 01 Aug 2019 04:14:29 +0000 Subject: [issue29750] smtplib doesn't handle unicode passwords In-Reply-To: <1488919224.48.0.0966376973087.issue29750@psf.upfronthosting.co.za> Message-ID: <1564632869.63.0.231997316012.issue29750@roundup.psfhosted.org> Windson Yang added the comment: I just updated the PR ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 01:15:50 2019 From: report at bugs.python.org (Dong-hee Na) Date: Thu, 01 Aug 2019 05:15:50 +0000 Subject: [issue33668] Wrong behavior of help function on module In-Reply-To: <1527517343.16.0.682650639539.issue33668@psf.upfronthosting.co.za> Message-ID: <1564636550.91.0.879221525687.issue33668@roundup.psfhosted.org> Dong-hee Na added the comment: I close PR 8284. If there is a chance to work with this issue. Please let me know Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 01:43:10 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 01 Aug 2019 05:43:10 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564638190.48.0.559828829218.issue18049@roundup.psfhosted.org> Ronald Oussoren added the comment: New changeset 1a057bab0f18d6ad843ce321d1d77a4819497ae4 by Ronald Oussoren in branch 'master': bpo-18049: Sync thread stack size to main thread size on macOS (GH-14748) https://github.com/python/cpython/commit/1a057bab0f18d6ad843ce321d1d77a4819497ae4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 01:43:20 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 01 Aug 2019 05:43:20 +0000 Subject: [issue25312] Cryptic error message if incorrect spec is set on a callable mock In-Reply-To: <1443982028.68.0.922333733292.issue25312@psf.upfronthosting.co.za> Message-ID: <1564638200.74.0.654095514122.issue25312@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Using spec only checks for the attribute to be present and not the signature of the actual attribute being called. You might need autospec for this behavior. The below example to use create_autospec does the correct validation for mock_foo.func. There is an open issue to make spec also do signature validation but it could go into 3.9 only if accepted since it changes semantics : issue30587. Regarding the error message being cryptic there are other issues open on assertion error being displayed with actual and expected call list being same. I would propose closing this issue. Maybe the docs could be updated about this behavior to make sure using spec is more clear on the expected behavior. https://docs.python.org/3/library/unittest.mock.html#unittest.mock.Mock spec: This can be either a list of strings or an existing object (a class or instance) that acts as the specification for the mock object. If you pass in an object then a list of strings is formed by calling dir on the object (excluding unsupported magic attributes and methods). Accessing any attribute not in this list will raise an AttributeError. # bpo25312.py from unittest.mock import call, create_autospec, Mock import inspect class Foo: def __init__(self, val): pass def func(self): pass class FooMock(Mock): def _get_child_mock(self, **kwargs): return create_autospec(Foo) mock_foo = FooMock() print(inspect.signature(mock_foo.func)) # Signature is correct with create_autospec whereas with Mock(spec=Foo) it is (*args, **kwargs) mock_foo.func() # Raises TypeError with (val) being signature. mock_foo.func.assert_has_calls([call()]) ? cpython git:(master) ? ./python.exe bpo25312.py (val) Traceback (most recent call last): File "/Users/karthikeyansingaravelan/stuff/python/cpython/bpo25312.py", line 19, in mock_foo.func() File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py", line 1027, in __call__ self._mock_check_sig(*args, **kwargs) File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py", line 119, in checksig sig.bind(*args, **kwargs) File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/inspect.py", line 3025, in bind return self._bind(args, kwargs) File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/inspect.py", line 2940, in _bind raise TypeError(msg) from None TypeError: missing a required argument: 'val' ---------- nosy: +cjw296, mariocj89 versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 01:43:22 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 01 Aug 2019 05:43:22 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564638202.92.0.764334438891.issue18049@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14814 pull_request: https://github.com/python/cpython/pull/15065 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 02:00:38 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 01 Aug 2019 06:00:38 +0000 Subject: [issue26752] Mock(2.0.0).assert_has_calls() raise AssertionError in two same calls In-Reply-To: <1460619804.34.0.222553592589.issue26752@psf.upfronthosting.co.za> Message-ID: <1564639238.91.0.484484204731.issue26752@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I proposed a PR for issue36871 which has the same issue with constructor signature being used for method calls when specced. I also checked the patch with the examples reported here regarding signature mismatch and they seem to be fixed. So perhaps this can be closed once issue36871 is merged. The issue with error message being cryptic in issue27715 when self is passed or not for sig.bind is not yet solved though. Please let me know if there is anything missed with the PR 13261 so that I can add relevant tests. Thanks. ---------- components: +Library (Lib) -Tests versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 02:35:30 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Thu, 01 Aug 2019 06:35:30 +0000 Subject: [issue37491] IndexError in get_bare_quoted_string In-Reply-To: <1562141971.16.0.876863205208.issue37491@roundup.psfhosted.org> Message-ID: <1564641330.59.0.786677927152.issue37491@roundup.psfhosted.org> St?phane Wirtel added the comment: @barry the 3 PR have been merged, do you think we could close this issue? Thank you ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 03:22:52 2019 From: report at bugs.python.org (Inada Naoki) Date: Thu, 01 Aug 2019 07:22:52 +0000 Subject: [issue37729] gc: stats from multi process are mixed up In-Reply-To: <1564565728.92.0.202188074199.issue37729@roundup.psfhosted.org> Message-ID: <1564644172.76.0.862605812421.issue37729@roundup.psfhosted.org> Change by Inada Naoki : ---------- versions: -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 04:09:28 2019 From: report at bugs.python.org (Kal Sze) Date: Thu, 01 Aug 2019 08:09:28 +0000 Subject: [issue37595] Python 3.7.4 does not build on Raspbian Buster In-Reply-To: <1563155199.46.0.613653313897.issue37595@roundup.psfhosted.org> Message-ID: <1564646968.54.0.928526750362.issue37595@roundup.psfhosted.org> Kal Sze added the comment: Yes, removing --enable-optimizations and keeping all other configure options allows me to build. However, I think most people *do* want optimizations, especially because the Raspberry Pi itself already isn't very fast. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 05:12:56 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Aug 2019 09:12:56 +0000 Subject: [issue36273] test_thread leaks a core dump on PPC64 AIX 3.x In-Reply-To: <1552407244.81.0.665825370239.issue36273@roundup.psfhosted.org> Message-ID: <1564650776.47.0.867921719697.issue36273@roundup.psfhosted.org> STINNER Victor added the comment: > Again - how can I get the core (dump) mentioned in the error message. When I force this situation I have several core dumps - not "the one". You have to contact the owner of the buildbot worker. From a build, you can click on the Worker tab. For PPC64 AIX, I see: David Edelsohn ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 05:13:11 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Aug 2019 09:13:11 +0000 Subject: [issue36273] test_thread leaks a core dump on PPC64 AIX 3.x In-Reply-To: <1552407244.81.0.665825370239.issue36273@roundup.psfhosted.org> Message-ID: <1564650791.0.0.423751960997.issue36273@roundup.psfhosted.org> STINNER Victor added the comment: test_threading has a similar issue, still on PPC64 AIX 3.x: https://buildbot.python.org/all/#builders/10/builds/3171 test_recursion_limit (test.test_threading.ThreadingExceptionTests) ... FAIL test_releasing_unacquired_lock (test.test_threading.ThreadingExceptionTests) ... ok test_start_thread_again (test.test_threading.ThreadingExceptionTests) ... ok test_init_immutable_default_args (test.test_threading.TimerTests) ... ok ====================================================================== FAIL: test_recursion_limit (test.test_threading.ThreadingExceptionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_threading.py", line 1088, in test_recursion_limit self.assertEqual(p.returncode, 0, "Unexpected error: " + stderr.decode()) AssertionError: -11 != 0 : Unexpected error: ---------------------------------------------------------------------- Ran 168 tests in 12.623s FAILED (failures=1) Warning -- files was modified by test_threading Before: [] After: ['core'] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 05:15:47 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Aug 2019 09:15:47 +0000 Subject: [issue36273] test_thread leaks a core dump on PPC64 AIX 3.x In-Reply-To: <1552407244.81.0.665825370239.issue36273@roundup.psfhosted.org> Message-ID: <1564650947.6.0.424298704763.issue36273@roundup.psfhosted.org> STINNER Victor added the comment: Same test_threading crash on POWER6 AIX 3.x: https://buildbot.python.org/all/#/builders/161/builds/1430 This build was triggered by the change of bpo-18049 which is supposed to only impact macOS, but it does touch test_recursion_limit... can it be related to the regression? https://github.com/python/cpython/commit/1a057bab0f18d6ad843ce321d1d77a4819497ae4 test_recursion_limit (test.test_threading.ThreadingExceptionTests) ... FAIL test_releasing_unacquired_lock (test.test_threading.ThreadingExceptionTests) ... ok test_start_thread_again (test.test_threading.ThreadingExceptionTests) ... ok test_init_immutable_default_args (test.test_threading.TimerTests) ... ok ====================================================================== FAIL: test_recursion_limit (test.test_threading.ThreadingExceptionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_threading.py", line 1088, in test_recursion_limit self.assertEqual(p.returncode, 0, "Unexpected error: " + stderr.decode()) AssertionError: -11 != 0 : Unexpected error: ---------------------------------------------------------------------- Ran 168 tests in 12.623s FAILED (failures=1) Warning -- files was modified by test_threading Before: [] After: ['core'] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 05:16:44 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Aug 2019 09:16:44 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564651004.64.0.555847763437.issue18049@roundup.psfhosted.org> STINNER Victor added the comment: I'm not sure if it's related, but test_threading.test_recursion_limit() started to crash on two AIX buildbot workers after commit 1a057bab0f18d6ad843ce321d1d77a4819497ae4: https://bugs.python.org/issue36273#msg348845 ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 05:25:01 2019 From: report at bugs.python.org (David Lewis) Date: Thu, 01 Aug 2019 09:25:01 +0000 Subject: [issue37736] asyncio.wait_for is still confusing Message-ID: <1564651501.71.0.316479365632.issue37736@roundup.psfhosted.org> New submission from David Lewis : This issue is a follow up to previous discussions about confusing results with asyncio.wait_for. In the current implementation, it seems unintuitive that a coroutine with a timeout argument may easily wait forever. Perhaps wait_for could use an await_cancellation=True kwarg. Prior issues: a) "It's a feature, not a bug" - Guido https://github.com/python/asyncio/issues/253#issuecomment-120020018 b) "I don't feel comfortable with asyncio living with this bug till 3.8." - Yury https://bugs.python.org/issue32751#msg318065 Originally, wait_for would cancel the future and raise TimeoutError immediately. In the case of a Task, it could remain active for some time after the timeout, since its cancellation is potentially asynchronous. In (a), this behaviour was defended, since waiting on the cancellation would violate the implicit contract of the timeout argument to wait_for(). While the documentation suggests it's a poor idea, it's not illegal for a task to defer or entirely refuse cancellation. In (b), the task outliving the TimeoutError was considered a bug, and the behaviour changed to its current state. To address the issue raised in (a), the documentation for wait_for now contains the line "The function will wait until the future is actually cancelled, so the total wait time may exceed the timeout." However, we still have the case where a misbehaving Task can cause wait_for to hang indefinitely. For example, the following program doesn't terminate: import asyncio, contextlib async def bad(): while True: with contextlib.suppress(asyncio.CancelledError): await asyncio.sleep(1) print("running...") if __name__ == '__main__': asyncio.run(asyncio.wait_for(bad(), 1)) More realistically, the task may have cooperative cancellation logic that waits for something else to be tidied up: try: await wait_for(some_task(service), 10) except TimeoutError: ... finally: service.stop() ---------- components: asyncio messages: 348848 nosy: David Lewis, asvetlov, yselivanov priority: normal severity: normal status: open title: asyncio.wait_for is still confusing type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 07:34:19 2019 From: report at bugs.python.org (Tal Cohen) Date: Thu, 01 Aug 2019 11:34:19 +0000 Subject: [issue37724] [[Errno 17] File exists: ] # Try create directories that are not part of the archive with In-Reply-To: <1564525622.36.0.964910267569.issue37724@roundup.psfhosted.org> Message-ID: <1564659259.97.0.941853366527.issue37724@roundup.psfhosted.org> Tal Cohen <3talcohen at gmail.com> added the comment: Thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 08:10:44 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 01 Aug 2019 12:10:44 +0000 Subject: [issue37461] email.parser.Parser hang In-Reply-To: <1561951273.26.0.821144691276.issue37461@roundup.psfhosted.org> Message-ID: <1564661444.55.0.060169251119.issue37461@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: 3.5 also seems to be affected. git cherry pick works and the patch fixes the problem so I assume the backport would be straightforward. Since 3.5 is open for security fixes with 3.5.8 as next release I am adding Larry. $ git cherry-pick a4a994b Performing inexact rename detection: 100% (566740/566740), done. [detached HEAD 9877e9283c] bpo-37461: Fix infinite loop in parsing of specially crafted email headers (GH-14794) Author: Abhilash Raj Date: Wed Jul 17 09:44:27 2019 -0700 3 files changed, 12 insertions(+) create mode 100644 Misc/NEWS.d/next/Security/2019-07-16-08-11-00.bpo-37461.1Ahz7O.rst ---------- nosy: +larry versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 08:28:25 2019 From: report at bugs.python.org (R. David Murray) Date: Thu, 01 Aug 2019 12:28:25 +0000 Subject: [issue37491] IndexError in get_bare_quoted_string In-Reply-To: <1562141971.16.0.876863205208.issue37491@roundup.psfhosted.org> Message-ID: <1564662505.79.0.526070130972.issue37491@roundup.psfhosted.org> Change by R. David Murray : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 08:42:01 2019 From: report at bugs.python.org (R. David Murray) Date: Thu, 01 Aug 2019 12:42:01 +0000 Subject: [issue37532] email.header.make_header() doesn't work if any `ascii` code is out of range(128) In-Reply-To: <1562707246.84.0.835768356919.issue37532@roundup.psfhosted.org> Message-ID: <1564663321.83.0.209773547758.issue37532@roundup.psfhosted.org> R. David Murray added the comment: The input header is not valid (non-ascii is not allowed in headers), so you shouldn't expect make_header to do anything sensible. Note that this is the legacy API, which is a toolkit and does not hold your hand when it comes to RFC compliance. Aside from any other concerns, this is long standing behavior (it is the same in python2), and it doesn't make sense to change the behavior of a legacy API. ---------- resolution: -> not a bug stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 09:18:10 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Aug 2019 13:18:10 +0000 Subject: [issue36302] distutils creates unreproducible .so files In-Reply-To: <1552653033.32.0.635728597537.issue36302@roundup.psfhosted.org> Message-ID: <1564665490.56.0.0247709329563.issue36302@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 0d30ae1a03102de07758650af9243fd31211325a by Victor Stinner (Bernhard M. Wiedemann) in branch 'master': bpo-36302: Sort list of sources (GH-12341) https://github.com/python/cpython/commit/0d30ae1a03102de07758650af9243fd31211325a ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 09:19:58 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Aug 2019 13:19:58 +0000 Subject: [issue36302] distutils creates unreproducible .so files In-Reply-To: <1552653033.32.0.635728597537.issue36302@roundup.psfhosted.org> Message-ID: <1564665598.55.0.276538816523.issue36302@roundup.psfhosted.org> STINNER Victor added the comment: I'm not excited about backporting this change to Python 3.8 and older. Python 3.8 also switch to its feature freeze for Python 3.8.0. This change is borderline between bugfix and feature. In case of doubt, I prefer to do nothing. See concerns in the PR discussion: https://github.com/python/cpython/pull/12341#issuecomment-473361985 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 -Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 09:29:49 2019 From: report at bugs.python.org (David CARLIER) Date: Thu, 01 Aug 2019 13:29:49 +0000 Subject: [issue37737] mmap module track anonymous page on macOS Message-ID: <1564666189.5.0.946971238191.issue37737@roundup.psfhosted.org> Change by David CARLIER : ---------- components: macOS nosy: devnexen, ned.deily, ronaldoussoren priority: normal pull_requests: 14815 severity: normal status: open title: mmap module track anonymous page on macOS versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 09:40:24 2019 From: report at bugs.python.org (Michael Felt) Date: Thu, 01 Aug 2019 13:40:24 +0000 Subject: [issue36273] test_thread leaks a core dump on PPC64 AIX 3.x In-Reply-To: <1564650947.6.0.424298704763.issue36273@roundup.psfhosted.org> Message-ID: <592f955f-3a2a-6a8b-4d47-ff52fd38c0ae@felt.demon.nl> Michael Felt added the comment: On 01/08/2019 11:15, STINNER Victor wrote: > FAILED (failures=1) > Warning -- files was modified by test_threading > Before: [] > After: ['core'] Thanks. I'll look again (on my bot) and other test systems. What I assume has not been clear about my question - from the output I see that there is, somewhere, a file named 'core' - but I can never find it - and my assumption is that the test environment is cleaning up after itself. So, rephrased - is there a way to stop running test cycle when there is an environment error, especially with a core dump, so that it can be examined for further clues. Michael ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 09:45:15 2019 From: report at bugs.python.org (Marius Gedminas) Date: Thu, 01 Aug 2019 13:45:15 +0000 Subject: [issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information Message-ID: <1564667115.2.0.875397124654.issue37738@roundup.psfhosted.org> New submission from Marius Gedminas : curses.addch() ignores color information if I pass it a string of length one. Color works fine if I pass it a byte string or an int. Here's a reproducer: ### start of example ### import curses def main(stdscr): curses.start_color() curses.use_default_colors() curses.init_pair(1, curses.COLOR_RED, -1) curses.init_pair(2, curses.COLOR_GREEN, -1) curses.curs_set(0) stdscr.addch("a", curses.color_pair(1)) stdscr.addch("b", curses.color_pair(2) | curses.A_BOLD) stdscr.addch(b"c", curses.color_pair(1)) stdscr.addch(b"d", curses.color_pair(2) | curses.A_BOLD) stdscr.addch(ord("e"), curses.color_pair(1)) stdscr.addch(ord("f"), curses.color_pair(2) | curses.A_BOLD) stdscr.refresh() stdscr.getch() curses.wrapper(main) ### end of example ### On Python 2.7 this prints 'abcdef' in alternating red and green. On Python 3.5 through 3.8 this prints 'ab' in white and the rest in red/green. Note that only color pair information is lost -- the bold attribute is correctly set on the 'b'. ---------- components: Library (Lib) messages: 348855 nosy: mgedmin priority: normal severity: normal status: open title: curses.addch('a', curses.color_pair(1)) ignores the color information versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 10:17:57 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Aug 2019 14:17:57 +0000 Subject: [issue37726] Tutorial should not recommend getopt In-Reply-To: <1564546690.91.0.192257836854.issue37726@roundup.psfhosted.org> Message-ID: <1564669077.29.0.263810682785.issue37726@roundup.psfhosted.org> Guido van Rossum added the comment: New changeset 2491134029b195d3159a489e1803ee22a7839b41 by Guido van Rossum (mental) in branch 'master': bpo-37726: Prefer argparse over getopt in stdlib tutorial (#15052) https://github.com/python/cpython/commit/2491134029b195d3159a489e1803ee22a7839b41 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 10:19:06 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 01 Aug 2019 14:19:06 +0000 Subject: [issue37726] Tutorial should not recommend getopt In-Reply-To: <1564546690.91.0.192257836854.issue37726@roundup.psfhosted.org> Message-ID: <1564669146.02.0.000773304919201.issue37726@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14816 pull_request: https://github.com/python/cpython/pull/15069 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 10:19:15 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 01 Aug 2019 14:19:15 +0000 Subject: [issue37726] Tutorial should not recommend getopt In-Reply-To: <1564546690.91.0.192257836854.issue37726@roundup.psfhosted.org> Message-ID: <1564669155.9.0.151432808818.issue37726@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14817 pull_request: https://github.com/python/cpython/pull/15070 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 10:35:04 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Aug 2019 14:35:04 +0000 Subject: [issue37726] Tutorial should not recommend getopt In-Reply-To: <1564546690.91.0.192257836854.issue37726@roundup.psfhosted.org> Message-ID: <1564670104.35.0.199229875129.issue37726@roundup.psfhosted.org> Guido van Rossum added the comment: New changeset dcc53ebbff384076b0763c1f842966c189417071 by Guido van Rossum (Miss Islington (bot)) in branch '3.8': bpo-37726: Prefer argparse over getopt in stdlib tutorial (GH-15052) (#15070) https://github.com/python/cpython/commit/dcc53ebbff384076b0763c1f842966c189417071 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 10:35:23 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Aug 2019 14:35:23 +0000 Subject: [issue37726] Tutorial should not recommend getopt In-Reply-To: <1564546690.91.0.192257836854.issue37726@roundup.psfhosted.org> Message-ID: <1564670123.57.0.165563217091.issue37726@roundup.psfhosted.org> Guido van Rossum added the comment: New changeset 8990ac0ab0398bfb9c62031288030fe7c630c2c7 by Guido van Rossum (Miss Islington (bot)) in branch '3.7': bpo-37726: Prefer argparse over getopt in stdlib tutorial (GH-15052) (#15069) https://github.com/python/cpython/commit/8990ac0ab0398bfb9c62031288030fe7c630c2c7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 10:36:25 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Aug 2019 14:36:25 +0000 Subject: [issue37726] Tutorial should not recommend getopt In-Reply-To: <1564546690.91.0.192257836854.issue37726@roundup.psfhosted.org> Message-ID: <1564670185.41.0.090343521796.issue37726@roundup.psfhosted.org> Guido van Rossum added the comment: Thanks mental! All done. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 10:36:53 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Aug 2019 14:36:53 +0000 Subject: [issue37726] Tutorial should not recommend getopt In-Reply-To: <1564546690.91.0.192257836854.issue37726@roundup.psfhosted.org> Message-ID: <1564670213.69.0.912888265475.issue37726@roundup.psfhosted.org> Change by Guido van Rossum : ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 10:39:00 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 01 Aug 2019 14:39:00 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564670340.65.0.0205758790229.issue18049@roundup.psfhosted.org> miss-islington added the comment: New changeset 8399641c34d8136c3151fda6461cc4727a20b28e by Miss Islington (bot) in branch '3.8': bpo-18049: Sync thread stack size to main thread size on macOS (GH-14748) https://github.com/python/cpython/commit/8399641c34d8136c3151fda6461cc4727a20b28e ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 10:43:26 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Aug 2019 14:43:26 +0000 Subject: [issue36273] test_thread leaks a core dump on PPC64 AIX 3.x In-Reply-To: <1552407244.81.0.665825370239.issue36273@roundup.psfhosted.org> Message-ID: <1564670606.66.0.481960966942.issue36273@roundup.psfhosted.org> STINNER Victor added the comment: """ What I assume has not been clear about my question - from the output I see that there is, somewhere, a file named 'core' - but I can never find it - and my assumption is that the test environment is cleaning up after itself. """ Right, regrtest removes all temporary directories used for tests. You should try to extract the code run by the test and run it manually. For example for test_recursion_limit(), you can use attached recurse.py. ---------- Added file: https://bugs.python.org/file48525/recurse.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 11:12:29 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Aug 2019 15:12:29 +0000 Subject: [issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information In-Reply-To: <1564667115.2.0.875397124654.issue37738@roundup.psfhosted.org> Message-ID: <1564672349.09.0.171559928492.issue37738@roundup.psfhosted.org> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +14818 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15071 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 11:13:21 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Aug 2019 15:13:21 +0000 Subject: [issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information In-Reply-To: <1564667115.2.0.875397124654.issue37738@roundup.psfhosted.org> Message-ID: <1564672401.29.0.467362214172.issue37738@roundup.psfhosted.org> STINNER Victor added the comment: stdscr.addch(str, color_pair) is implemented with: setcchar(&wcval, wstr, attr, 0, NULL); rtn = wadd_wch(self->win, &wcval); whereas stdscr.addch(bytes, color_pair) is implemented with: rtn = waddch(self->win, cch | (attr_t) attr); The 4th argument of setcchar() is "short color_pair": Python always pass 0. It seems to be your bug. Attached PR 15071 fix this bug. Note: Python 3.5 and 3.6 don't accept bugfixes anymore, only security fixes. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 11:18:31 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Aug 2019 15:18:31 +0000 Subject: [issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information In-Reply-To: <1564667115.2.0.875397124654.issue37738@roundup.psfhosted.org> Message-ID: <1564672711.24.0.824072325472.issue37738@roundup.psfhosted.org> STINNER Victor added the comment: I'm able to reproduce the issue on Fedora 30: Python 3.7.4 with ncurses-libs-6.1-10.20180923.fc30.x86_64. vstinner at apu$ cat /etc/fedora-release Fedora release 30 (Thirty) vstinner at apu$ python3 -VV Python 3.7.4 (default, Jul 9 2019, 16:32:37) [GCC 9.1.1 20190503 (Red Hat 9.1.1-1)] vstinner at apu$ python3 -c 'import _curses; print(_curses.__file__)' /usr/lib64/python3.7/lib-dynload/_curses.cpython-37m-x86_64-linux-gnu.so vstinner at apu$ ldd $(python3 -c 'import _curses; print(_curses.__file__)') linux-vdso.so.1 (0x00007ffe6f1b4000) libncursesw.so.6 => /lib64/libncursesw.so.6 (0x00007f1acf456000) libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f1acf427000) libpython3.7m.so.1.0 => /lib64/libpython3.7m.so.1.0 (0x00007f1acf0de000) libc.so.6 => /lib64/libc.so.6 (0x00007f1acef18000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f1acef12000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1aceef1000) libutil.so.1 => /lib64/libutil.so.1 (0x00007f1aceeea000) libm.so.6 => /lib64/libm.so.6 (0x00007f1aceda4000) /lib64/ld-linux-x86-64.so.2 (0x00007f1acf4dc000) vstinner at apu$ rpm -qf /lib64/libncursesw.so.6 ncurses-libs-6.1-10.20180923.fc30.x86_64 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 11:53:55 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Aug 2019 15:53:55 +0000 Subject: [issue3753] bytearray incompatible with y# In-Reply-To: <1220285023.36.0.49129522463.issue3753@psf.upfronthosting.co.za> Message-ID: <1564674835.68.0.40243199633.issue3753@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +14819 pull_request: https://github.com/python/cpython/pull/15072 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 12:03:23 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Aug 2019 16:03:23 +0000 Subject: [issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information In-Reply-To: <1564667115.2.0.875397124654.issue37738@roundup.psfhosted.org> Message-ID: <1564675403.22.0.393533478319.issue37738@roundup.psfhosted.org> Change by STINNER Victor : ---------- versions: +Python 3.9 -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 12:23:02 2019 From: report at bugs.python.org (Su Zhu) Date: Thu, 01 Aug 2019 16:23:02 +0000 Subject: [issue37739] list(filter) returns [] ??? Message-ID: <1564676582.32.0.410232765618.issue37739@roundup.psfhosted.org> New submission from Su Zhu : The filter become empty after serving as an argument of list(). Python 3.6.7 (default, Oct 22 2018, 11:32:17) [GCC 8.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> a = filter(lambda x:x, [1,2,3]) >>> list(a) [1, 2, 3] >>> list(a) [] ---------- components: Demos and Tools messages: 348864 nosy: zhusu.china priority: normal severity: normal status: open title: list(filter) returns [] ??? type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 12:26:32 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Thu, 01 Aug 2019 16:26:32 +0000 Subject: [issue37739] list(filter) returns [] ??? In-Reply-To: <1564676582.32.0.410232765618.issue37739@roundup.psfhosted.org> Message-ID: <1564676792.31.0.435942895424.issue37739@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi Su Zhu, this is expected, as per the documentation, filter returns an iterable and not a list. The first `list(a)` consumes the iterable so it is empty when doing the second `list(a)`. You can see the same behavior when creating an iterable manually: >>> a = iter([1, 2, 3]) >>> list(a) [1, 2, 3] >>> list(a) [] If you need to keep the result in a list, you can do: >>> a = list(filter(lambda x:x, [1,2,3])) ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 12:30:26 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 01 Aug 2019 16:30:26 +0000 Subject: [issue37739] list(filter) returns [] ??? In-Reply-To: <1564676582.32.0.410232765618.issue37739@roundup.psfhosted.org> Message-ID: <1564677026.46.0.263171279991.issue37739@roundup.psfhosted.org> Ned Deily added the comment: https://docs.python.org/3/library/functions.html#filter ---------- nosy: +ned.deily resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 12:36:50 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 01 Aug 2019 16:36:50 +0000 Subject: [issue37461] email.parser.Parser hang In-Reply-To: <1561951273.26.0.821144691276.issue37461@roundup.psfhosted.org> Message-ID: <1564677410.85.0.987977513511.issue37461@roundup.psfhosted.org> Ned Deily added the comment: New changeset 1789bbdd3e03023951a39933ef12dee0a03be616 by Ned Deily (Miss Islington (bot)) in branch '3.6': bpo-37461: Fix infinite loop in parsing of specially crafted email headers (GH-14794) (GH-14817) https://github.com/python/cpython/commit/1789bbdd3e03023951a39933ef12dee0a03be616 ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 12:49:31 2019 From: report at bugs.python.org (Zackery Spytz) Date: Thu, 01 Aug 2019 16:49:31 +0000 Subject: [issue34880] About the "assert" bytecode In-Reply-To: <1538549910.96.0.545547206417.issue34880@psf.upfronthosting.co.za> Message-ID: <1564678171.38.0.83023301855.issue34880@roundup.psfhosted.org> Change by Zackery Spytz : ---------- keywords: +patch pull_requests: +14820 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15073 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 12:51:26 2019 From: report at bugs.python.org (Zackery Spytz) Date: Thu, 01 Aug 2019 16:51:26 +0000 Subject: [issue34880] About the "assert" bytecode In-Reply-To: <1538549910.96.0.545547206417.issue34880@psf.upfronthosting.co.za> Message-ID: <1564678286.96.0.755485128975.issue34880@roundup.psfhosted.org> Change by Zackery Spytz : ---------- components: +Interpreter Core nosy: +ZackerySpytz versions: +Python 3.9 -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 13:51:55 2019 From: report at bugs.python.org (Yun Li) Date: Thu, 01 Aug 2019 17:51:55 +0000 Subject: [issue37532] email.header.make_header() doesn't work if any `ascii` code is out of range(128) In-Reply-To: <1564663321.83.0.209773547758.issue37532@roundup.psfhosted.org> Message-ID: Yun Li added the comment: Hi, David: I don't think your argument stands here. The whole world does not just include English speaking countries. There are Spanish, Russian, Chinese, etc. Any legacy packages should support all languages instead of just English. This is definitely a bug in this package. I hope that the python support team should fix this issue or simply add the "support English only" description in the function explicitly . Otherwise it is very annoying for other countries to use this package. Thanks! Yun On Thu, Aug 1, 2019 at 5:42 AM R. David Murray wrote: > > R. David Murray added the comment: > > The input header is not valid (non-ascii is not allowed in headers), so > you shouldn't expect make_header to do anything sensible. Note that this > is the legacy API, which is a toolkit and does not hold your hand when it > comes to RFC compliance. Aside from any other concerns, this is long > standing behavior (it is the same in python2), and it doesn't make sense to > change the behavior of a legacy API. > > ---------- > resolution: -> not a bug > stage: patch review -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 13:58:33 2019 From: report at bugs.python.org (mzbuild) Date: Thu, 01 Aug 2019 17:58:33 +0000 Subject: [issue37740] Python 3.7 sh hangs when using in threads, forking and logging Message-ID: <1564682313.44.0.793879611367.issue37740@roundup.psfhosted.org> New submission from mzbuild : Hi, We use the sh module in a threaded context to execute shell commands. When we were migrating to python 3 from python 2 we encountered some commands hanging. We created a test script that recreates the issue we are seeing. `import sh import logging import concurrent.futures.thread def execmd(exe): print(sh.ls()) execution_pool = concurrent.futures.thread.ThreadPoolExecutor(20) i = 0 thread_results = [] while i<500: i+= 1 thread_results.append(execution_pool.map(execmd, ['ls'])) execution_pool.shutdown() When running this in python 3.7 it hangs but in python 3.6 it works fine. We think it is releated to this issue https://bugs.python.org/issue36533. Installing the latest 3.7.4 didn't fix the issue. The sh module uses logging and forking and the top script uses threading so we think there is a locking issue with 3.7. Any help would be great. ---------- components: Library (Lib) messages: 348869 nosy: cagney, ebizzinfotech, gregory.p.smith, hugh, lukasz.langa, mzbuild, ned.deily priority: normal severity: normal status: open title: Python 3.7 sh hangs when using in threads, forking and logging type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 14:16:42 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 01 Aug 2019 18:16:42 +0000 Subject: [issue37740] Python 3.7 sh hangs when using in threads, forking and logging In-Reply-To: <1564682313.44.0.793879611367.issue37740@roundup.psfhosted.org> Message-ID: <1564683402.28.0.180462352364.issue37740@roundup.psfhosted.org> Gregory P. Smith added the comment: os.fork() cannot be safely used in an application that uses threads in any manner. This is not something Python can fix. This is a POSIX limitation. The "sh" module on PyPI is incompatible with threaded applications on POSIX platforms due to its use of os.fork(). https://github.com/amoffat/sh/blob/master/sh.py#L1861 Raise this issue with them. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 14:45:58 2019 From: report at bugs.python.org (R. David Murray) Date: Thu, 01 Aug 2019 18:45:58 +0000 Subject: [issue37532] email.header.make_header() doesn't work if any `ascii` code is out of range(128) In-Reply-To: <1562707246.84.0.835768356919.issue37532@roundup.psfhosted.org> Message-ID: <1564685158.94.0.152575707797.issue37532@roundup.psfhosted.org> R. David Murray added the comment: Right, and the python email package fully supports non ascii: >>> msg = EmailMessage() >>> msg['Subject'] = "Panam?- Casco Antiguo" >>> bytes(msg) b'Subject: =?utf-8?q?Panam=C3=A1-?= Casco Antiguo\n\n' >>> str(msg) 'Subject: Panam?- Casco Antiguo\n\n' >>> msg['subject'] 'Panam?- Casco Antiguo' make_header also supports non-ascii, you just have to tell it what charset you want to use. Like I said, make_header is part of the *legacy* API, and it really is a pain to use. That's why we wrote the new API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 14:47:05 2019 From: report at bugs.python.org (Brett Cannon) Date: Thu, 01 Aug 2019 18:47:05 +0000 Subject: [issue37741] importlib.metadata docs not showing up in the module index Message-ID: <1564685225.86.0.948746560612.issue37741@roundup.psfhosted.org> New submission from Brett Cannon : If you look at https://docs.python.org/3.9/py-modindex.html#cap-i you will see that importlib.metadata isn't listed (same goes for the 3.8 docs). Or are you leaving it out due to it being provisional? ---------- assignee: docs at python components: Documentation messages: 348872 nosy: barry, brett.cannon, docs at python, jaraco priority: normal severity: normal status: open title: importlib.metadata docs not showing up in the module index versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 15:22:57 2019 From: report at bugs.python.org (Tal Einat) Date: Thu, 01 Aug 2019 19:22:57 +0000 Subject: [issue37706] IDLE test_sidebar test_(click/drag)_selection fail on macOS 8.6 In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1564687377.26.0.903100010239.issue37706@roundup.psfhosted.org> Tal Einat added the comment: I can't reproduce this on a Mac now with the recent 3.8.0b3 installer: After removing the skipIf() decorators, the tests all pass as expected. Ned, can you check with this installer? If it still fails for you, can you give some details about your Mac, e.g. the screen resolution you are using and whether you are using any kind of scaling? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 15:51:49 2019 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 01 Aug 2019 19:51:49 +0000 Subject: [issue37741] importlib.metadata docs not showing up in the module index In-Reply-To: <1564685225.86.0.948746560612.issue37741@roundup.psfhosted.org> Message-ID: <1564689109.23.0.661997058183.issue37741@roundup.psfhosted.org> Fred L. Drake, Jr. added the comment: Provisional status should not cause a module or other API element to be omitted from the indexes. So long as it's marked provisional where it's described, it should be locatable. ---------- nosy: +fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 16:00:20 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 01 Aug 2019 20:00:20 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564689620.71.0.0295028176791.issue18049@roundup.psfhosted.org> Ronald Oussoren added the comment: That is related, my patch removes a guard that should enable this test only on macOS. This fragment is the issue: - @unittest.skipUnless(sys.platform == 'darwin' and test.support.python_is_optimized(), - 'test macosx problem') I'll create a pull request for this. BTW. This does point to an issue with AIX though, this means it is possible to crash threads by deep recursion on AIX. But that's separate from this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 16:08:21 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 01 Aug 2019 20:08:21 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564690101.41.0.450390686468.issue18049@roundup.psfhosted.org> Ronald Oussoren added the comment: The patch to fix this should be: diff --git a/Lib/test/test_threading.py b/Lib/test/test_threading.py index 1466d25e94..658bc1c7a0 100644 --- a/Lib/test/test_threading.py +++ b/Lib/test/test_threading.py @@ -1057,6 +1057,7 @@ class ThreadingExceptionTests(BaseTestCase): lock = threading.Lock() self.assertRaises(RuntimeError, lock.release) + @unittest.skipUnless(sys.platform == 'darwin', 'test macos problem') def test_recursion_limit(self): # Issue 9670 # test that excessive recursion within a non-main thread causes --- PR will follow after I've run tests locally, I'll probably create the PR in the morning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 17:45:22 2019 From: report at bugs.python.org (Armin Rigo) Date: Thu, 01 Aug 2019 21:45:22 +0000 Subject: [issue34880] About the "assert" bytecode In-Reply-To: <1538549910.96.0.545547206417.issue34880@psf.upfronthosting.co.za> Message-ID: <1564695922.54.0.656441139799.issue34880@roundup.psfhosted.org> Change by Armin Rigo : ---------- nosy: -arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 19:22:33 2019 From: report at bugs.python.org (Damian Yurzola) Date: Thu, 01 Aug 2019 23:22:33 +0000 Subject: [issue37742] logging.getLogger accepts name='root' leading to confusion Message-ID: <1564701753.98.0.180548657893.issue37742@roundup.psfhosted.org> New submission from Damian Yurzola : 'root' should be a reserved name to avoid this: >>> import logging >>> a = logging.getLogger() >>> b = logging.getLogger('root') >>> a.name 'root' >>> b.name 'root' >>> a is b False ---------- components: Library (Lib) messages: 348877 nosy: yurzo priority: normal severity: normal status: open title: logging.getLogger accepts name='root' leading to confusion type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 19:33:04 2019 From: report at bugs.python.org (Antony Lee) Date: Thu, 01 Aug 2019 23:33:04 +0000 Subject: [issue37743] How should contextmanager/ContextDecorator work with generators? Message-ID: <1564702384.75.0.948740630584.issue37743@roundup.psfhosted.org> New submission from Antony Lee : The docs for ContextDecorator (of which contextmanager is a case) describe its semantics as: ... for any construct of the following form: def f(): with cm(): # Do stuff ContextDecorator lets you instead write: @cm() def f(): # Do stuff However, when decorating a generator, the equivalence is broken: from contextlib import contextmanager @contextmanager def cm(): print("start") yield print("stop") def gen_using_with(): with cm(): yield from map(print, range(2)) @cm() def gen_using_decorator(): yield from map(print, range(2)) print("using with") list(gen_using_with()) print("==========") print("using decorator") list(gen_using_decorator()) results in using with start 0 1 stop ========== using decorator start stop 0 1 i.e., when used as a decorator, the entire contextmanager is executed first before iterating over the generator (which is unsurprising given the implementation of ContextDecorator: ContextDecorator returns a function that executes the context manager and returns the generator, which is only iterated over later). Should this be considered as a bug in ContextDecorator, and should ContextDecorator instead detect when it is used to decorate a generator (e.g. with inspect.isgeneratorfunction), and switch its implementation accordingly in that case? ---------- components: Library (Lib) messages: 348878 nosy: Antony.Lee priority: normal severity: normal status: open title: How should contextmanager/ContextDecorator work with generators? versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 20:54:24 2019 From: report at bugs.python.org (Samuel Thibault) Date: Fri, 02 Aug 2019 00:54:24 +0000 Subject: [issue37744] thread native id support for GNU/Hurd Message-ID: <1564707264.79.0.323532185267.issue37744@roundup.psfhosted.org> New submission from Samuel Thibault : Hello, Here is a patch to add thread native ID support for GNU/Hurd. Samuel ---------- components: Interpreter Core files: hurd_thread_native_id.diff keywords: patch messages: 348879 nosy: samuel-thibault priority: normal severity: normal status: open title: thread native id support for GNU/Hurd versions: Python 3.8 Added file: https://bugs.python.org/file48526/hurd_thread_native_id.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 21:12:59 2019 From: report at bugs.python.org (Ma Lin) Date: Fri, 02 Aug 2019 01:12:59 +0000 Subject: [issue33408] Enable AF_UNIX support in Windows In-Reply-To: <1525257332.06.0.682650639539.issue33408@psf.upfronthosting.co.za> Message-ID: <1564708379.04.0.205456642344.issue33408@roundup.psfhosted.org> Ma Lin added the comment: The current AF_UNIX address family of Windows10 doesn't support datagram, adding this flag may break some cross-platform code: https://github.com/osbuild/osbuild/blob/9371eb9eaa3d0a7cab876eb4c7b70f519dfbd915/osbuild/__init__.py#L253 https://github.com/watsona4/dot_julia2/blob/5b7632b8089be01af706d8152555e711e0a81f06/conda/3/pkgs/python-3.7.3-h0371630_0/lib/python3.7/logging/handlers.py#L676 https://github.com/bognikol/Eleusis/blob/828672492b9cdb3444ddf466c0ac3055572277f7/Dependencies/02_macOS/40_gtk%2B/x64/lib/python2.7/test/test_socketserver.py#L177 https://github.com/sarnautov/python3/blob/005d75d8ac2b11a06707ce0184021a727d6fe844/lib/python3.6/test/test_asyncio/test_unix_events.py#L311 https://github.com/yanlianglai/ssr_python_leeblog/blob/8113fe3f32a250cc52e0cddad9761692dd840967/shadowsocks/manager.py#L60 ... So I'm -1 on adding AF_UNIX personally. I thought a compromise proposal: - if (building SDK >= 1804 and run-time Windows >= 1804), add a undocumented flag _WIN_AF_UNIX, its value is equal to AF_UNIX. - only use _WIN_AF_UNIX in stdlib, this is a black-box optimization. - if someone really need high performance, he/she can uses this undocumented flag privately. If one day Windows support full AF_UNIX, we can remove _WIN_AF_UNIX and add standard AF_UNIX. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 21:25:31 2019 From: report at bugs.python.org (Stefan Sullivan) Date: Fri, 02 Aug 2019 01:25:31 +0000 Subject: [issue11218] pattern=None when following documentation for load_tests and unittest.main() In-Reply-To: <1297758807.39.0.713611114484.issue11218@psf.upfronthosting.co.za> Message-ID: <1564709131.31.0.917436815026.issue11218@roundup.psfhosted.org> Stefan Sullivan added the comment: This seems like it directly contradicts the documentation for the discover method: "If a package (a directory containing a file named __init__.py) is found, the package will be checked for a load_tests function. If this exists then it will be called package.load_tests(loader, tests, pattern)." I believe this _is_ a functional bug. I have a use case where I have provided a root script with contents along the lines of for d in includes: test_dir = os.path.join(search_dir, d) if test_dir not in excludes: test_suite.addTests(test_loader.discover(test_dir, '*.py', search_dir)) and a load_tests function in one of those directory's __init__.py. However, since test discovery does not pass on the pattern, I cannot possibly discover what the pattern should have been. Furthermore, if I instead invoke test discovery on the command line using: python -m unittest discover -s /path/to/code -t /path/to/code -p *.py I again will see a load_tests invoked with pattern=None. What is the situation where load_tests will be invoked with a non-None pattern? Is there a workaround for how I'm supposed to get this pattern? Is there a convention or design pattern where I'm supposed to return everything and let the caller filter out the extra tests? As far as I can tell, the load_tests protocol is only relevant to packages (not modules) by virtue of its placement in the __init__.py file. However, the only way to load tests from a package is via discover, because there is no loadTestsFromPackage method (like there is for loadTestsFromModule). Have I misunderstood the load_tests protocol? Is there some special way to get a pattern? I feel that if the user really wanted to use their own pattern, being passed a string won't hurt anything, but converse is not true (at least for my use case) ---------- nosy: +Stefan Sullivan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 21:41:37 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 02 Aug 2019 01:41:37 +0000 Subject: [issue37743] How should contextmanager/ContextDecorator work with generators? In-Reply-To: <1564702384.75.0.948740630584.issue37743@roundup.psfhosted.org> Message-ID: <1564710097.84.0.867239105138.issue37743@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 21:42:12 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 02 Aug 2019 01:42:12 +0000 Subject: [issue37742] logging.getLogger accepts name='root' leading to confusion In-Reply-To: <1564701753.98.0.180548657893.issue37742@roundup.psfhosted.org> Message-ID: <1564710132.15.0.884770652299.issue37742@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 1 21:51:07 2019 From: report at bugs.python.org (Su Zhu) Date: Fri, 02 Aug 2019 01:51:07 +0000 Subject: [issue37739] list(filter) returns [] ??? In-Reply-To: <1564676582.32.0.410232765618.issue37739@roundup.psfhosted.org> Message-ID: <1564710667.33.0.486456327108.issue37739@roundup.psfhosted.org> Su Zhu added the comment: I see. Thank you very much! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 00:55:51 2019 From: report at bugs.python.org (hai shi) Date: Fri, 02 Aug 2019 04:55:51 +0000 Subject: [issue11654] errors in atexit hooks don't change process exit code In-Reply-To: <1300912017.1.0.699282992507.issue11654@psf.upfronthosting.co.za> Message-ID: <1564721751.49.0.758839246429.issue11654@roundup.psfhosted.org> hai shi added the comment: as antoine said in https://bugs.python.org/issue1257, this bug should be closed;) ---------- nosy: +shihai1991 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 00:57:28 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 04:57:28 +0000 Subject: [issue16970] argparse: bad nargs value raises misleading message In-Reply-To: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za> Message-ID: <1564721848.26.0.113455732396.issue16970@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14821 pull_request: https://github.com/python/cpython/pull/15074 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 00:57:30 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 04:57:30 +0000 Subject: [issue16970] argparse: bad nargs value raises misleading message In-Reply-To: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za> Message-ID: <1564721850.42.0.619424968519.issue16970@roundup.psfhosted.org> miss-islington added the comment: New changeset 4b3e97592376d5f8a3b75192b399a2da1be642cb by Miss Islington (bot) (tmblweed) in branch 'master': bpo-16970: Adding error message for invalid args (GH-14844) https://github.com/python/cpython/commit/4b3e97592376d5f8a3b75192b399a2da1be642cb ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 01:02:55 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 02 Aug 2019 05:02:55 +0000 Subject: [issue16970] argparse: bad nargs value raises misleading message In-Reply-To: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za> Message-ID: <1564722175.53.0.18719421612.issue16970@roundup.psfhosted.org> Guido van Rossum added the comment: The 3.8 backport will land automatically once the tests pass. The 3.7 backport ran into some trouble, probably a simple merge conflict. Sushma do you want to try your hands at this? It probably requires some learning about Git branches. We can also skip this, it's only an improved error message after all, and you can try something more fun instead. The 3.6 branch is closed except for security fixes, which this isn't. ---------- nosy: +gvanrossum versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 01:16:49 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 05:16:49 +0000 Subject: [issue16970] argparse: bad nargs value raises misleading message In-Reply-To: <1358251791.34.0.358251606196.issue16970@psf.upfronthosting.co.za> Message-ID: <1564723009.13.0.773381730511.issue16970@roundup.psfhosted.org> miss-islington added the comment: New changeset 1cc70322c99b80c123f9ff23a415d3da28b4ec74 by Miss Islington (bot) in branch '3.8': bpo-16970: Adding error message for invalid args (GH-14844) https://github.com/python/cpython/commit/1cc70322c99b80c123f9ff23a415d3da28b4ec74 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 01:36:39 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 02 Aug 2019 05:36:39 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564724199.73.0.634571643687.issue18049@roundup.psfhosted.org> Change by Ronald Oussoren : ---------- pull_requests: +14822 pull_request: https://github.com/python/cpython/pull/15075 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 01:51:54 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 02 Aug 2019 05:51:54 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564725114.76.0.0115477160923.issue18049@roundup.psfhosted.org> Ronald Oussoren added the comment: PR 15075 should fix this issue. As mentioned in that PR I do have a question w.r.t. the exact shape of that patch: I currently reintroduce a "skipUnless" decorator that only runs this test on macOS, I could also introduce one that just disables the test on AIX as that's where the test fails. P.S. According to this old developer works blog AIX has a very small default stack size for threads (like more BSD systems) and also has an API to change the size of those stacks. It's probably worthwhile to add some code to thread_pthread.h to do this. The blog: https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/don_t_forget_about_stack_size_limits_for_multi_threaded_applications_on_aix?lang=en ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 02:15:52 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 02 Aug 2019 06:15:52 +0000 Subject: [issue37743] How should contextmanager/ContextDecorator work with generators? In-Reply-To: <1564702384.75.0.948740630584.issue37743@roundup.psfhosted.org> Message-ID: <1564726552.99.0.0382728044309.issue37743@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 02:57:14 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 02 Aug 2019 06:57:14 +0000 Subject: [issue37742] logging.getLogger accepts name='root' leading to confusion In-Reply-To: <1564701753.98.0.180548657893.issue37742@roundup.psfhosted.org> Message-ID: <1564729034.76.0.161503127635.issue37742@roundup.psfhosted.org> Raymond Hettinger added the comment: It looks like the issue is that the root logger is missing from the manager's loggerDict. A suggested fix is to change the creation of the loggerDict in the Manager class: - self.loggerDict = {} + self.loggerDict = {rootnode.name: rootnode} This may have been omitted from the initial design to avoid reference cycles; however, with the advent of garbage collection this should no longer be an issue. Alternatively, a weak reference could be used. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 03:25:48 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 07:25:48 +0000 Subject: [issue37729] gc: stats from multi process are mixed up In-Reply-To: <1564565728.92.0.202188074199.issue37729@roundup.psfhosted.org> Message-ID: <1564730748.03.0.00859669496154.issue37729@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14823 pull_request: https://github.com/python/cpython/pull/15076 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 03:25:52 2019 From: report at bugs.python.org (Inada Naoki) Date: Fri, 02 Aug 2019 07:25:52 +0000 Subject: [issue37729] gc: stats from multi process are mixed up In-Reply-To: <1564565728.92.0.202188074199.issue37729@roundup.psfhosted.org> Message-ID: <1564730752.09.0.82549328211.issue37729@roundup.psfhosted.org> Inada Naoki added the comment: New changeset bf8162c8c45338470bbe487c8769bba20bde66c2 by Inada Naoki in branch 'master': bpo-37729: gc: write stats at once (GH-15050) https://github.com/python/cpython/commit/bf8162c8c45338470bbe487c8769bba20bde66c2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 03:28:15 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 02 Aug 2019 07:28:15 +0000 Subject: [issue14384] Add "default" kw argument to operator.itemgetter and operator.attrgetter In-Reply-To: <1332378559.49.0.430445927373.issue14384@psf.upfronthosting.co.za> Message-ID: <1564730895.08.0.518800078999.issue14384@roundup.psfhosted.org> Raymond Hettinger added the comment: Marking as closed for the reasons listed above. And there has been no further comments for over a year. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 03:47:32 2019 From: report at bugs.python.org (Michael Felt) Date: Fri, 02 Aug 2019 07:47:32 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564732052.11.0.345996372944.issue18049@roundup.psfhosted.org> Michael Felt added the comment: @Ronald - thanks. Gives me something to work from. Would not have found this so easily! But - where to put it... :) ---------- nosy: +Michael.Felt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 03:53:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 02 Aug 2019 07:53:06 +0000 Subject: [issue29636] Specifying indent in the json.tool command In-Reply-To: <1487880356.98.0.87296874253.issue29636@psf.upfronthosting.co.za> Message-ID: <1564732386.36.0.140849769543.issue29636@roundup.psfhosted.org> Raymond Hettinger added the comment: [Serhiy] > I don't think this PR should be merged. It adds too much options. [Daniel] > Since opening this issue, I've encountered several additional > instances where indentation control would have been nice. > I don't agree that jq is a sufficient substitute. I'm inclined to agree with Serhiy. While there are some handy command-line calls, they are secondary offshoots to the standard library and tend to be lightweight rather than full featured. They serve various purposes from quick demos to support of development and testing. In general, they aren't intended to be applications unto themselves: we don't document all command line tools in one place, we don't version number them, we don't maintain forums or web pages for them, we typically don't lock in their behaviors with a unit tests, we don't guarantee that they will be available across versions, and we periodically change their APIs (for example when switching from getopt to argparse). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 04:29:47 2019 From: report at bugs.python.org (Oleksandr Pavliuk) Date: Fri, 02 Aug 2019 08:29:47 +0000 Subject: [issue34788] ipaddress module fails on rfc4007 scoped IPv6 addresses In-Reply-To: <1537799403.03.0.956365154283.issue34788@psf.upfronthosting.co.za> Message-ID: <1564734587.57.0.465058485381.issue34788@roundup.psfhosted.org> Oleksandr Pavliuk added the comment: Please, pay attention to this issue. Pull request needs core review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 04:52:26 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 02 Aug 2019 08:52:26 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564735946.1.0.883883242778.issue18049@roundup.psfhosted.org> Ronald Oussoren added the comment: @Michael: The relevant code is in Python/thread_pthread.h: https://github.com/python/cpython/blob/bf8162c8c45338470bbe487c8769bba20bde66c2/Python/thread_pthread.h#L34 There are already blocks for macOS and FreeBSD, adding a block for AIX should be easy enough. I don't know what a good size for the stack would be though, the macOS size is large enough to not cause crashes with the default recursion limit in debug builds and was experimentally determined. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 05:09:46 2019 From: report at bugs.python.org (Michael Felt) Date: Fri, 02 Aug 2019 09:09:46 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564736986.12.0.271037628008.issue18049@roundup.psfhosted.org> Michael Felt added the comment: *** Looking in ./Python/thread_pthread.h" +252 #if defined(THREAD_STACK_SIZE) +253 PyThreadState *tstate = _PyThreadState_GET(); +254 size_t stacksize = tstate ? tstate->interp->pythread_stacksize : 0; +255 tss = (stacksize != 0) ? stacksize : THREAD_STACK_SIZE; +256 if (tss != 0) { +257 if (pthread_attr_setstacksize(&attrs, tss) != 0) { +258 pthread_attr_destroy(&attrs); +259 return PYTHREAD_INVALID_THREAD_ID; +260 } +261 } +262 #endif It appears asif the call needed (for AIX) - thread_attr_setstacksize(&attrs, tss) should be occurring. Can you help me with a quick program that reports back the actual stack size an AIX thread has? What may be at the heart of this (assuming the call above is working as expected) - the default memory size for AIX 32-bit is 256MB. Assuming 16 to 32MB is already in use - if I understand this "recurse" logic - after about 12-14 recursions the 256MB is consumed. In short (work calls) - it seems the API mentioned is already in place and what is happening in terms of "exception catching" is different. Looking forward to hints on how to dig further. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 05:48:23 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 02 Aug 2019 09:48:23 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564739303.68.0.77764309603.issue18049@roundup.psfhosted.org> Ronald Oussoren added the comment: That code is only called if THREAD_STACK_SIZE is defined. The block I mention defines it for macOS and FreeBSD, but not for other platforms. I therefore expect that this code is not used on AIX (which would be easy enough to verify by adding an #error to the block you mention. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 05:52:26 2019 From: report at bugs.python.org (Michael Felt) Date: Fri, 02 Aug 2019 09:52:26 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564739546.32.0.528055045668.issue18049@roundup.psfhosted.org> Michael Felt added the comment: Going to take a stab in the dark - the the issue lies here: "./Python/errors.c" #ifndef Py_NORMALIZE_RECURSION_LIMIT #define Py_NORMALIZE_RECURSION_LIMIT 32 #endif As there is not enough memory for this to run in the default memory model. However, 32 does not seem to be a counter limit: With this "hack" I get success: script = """if True: import threading def recurse(loop=0): loop = loop+1 if loop < 128+32+8+3: return recurse(loop) else: return def outer(): try: recurse() except RecursionError: pass w = threading.Thread(target=outer) w.start() w.join() print('end of main thread') """ So, I hope this helps point at where we need to look to find why RecursionError is not being returned when (I assume) memory runs out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 05:57:14 2019 From: report at bugs.python.org (LIU YONG) Date: Fri, 02 Aug 2019 09:57:14 +0000 Subject: [issue37733] Fail to build _curses module of Python 3.7.4 on AIX 7.1 using gcc In-Reply-To: <1564585726.95.0.247783534499.issue37733@roundup.psfhosted.org> Message-ID: <1564739834.18.0.503567178198.issue37733@roundup.psfhosted.org> LIU YONG added the comment: Additional information of environment OS - AIX 7.1 (7100-05-03-1838) gcc version 6.3.0 (GCC) ncurses-6.1-2.ppc ncurses-devel-6.1-2.ppc I had tried to build Python3.7.3 and Python3.6.9, it hit same errors It looks like some issue with ncurses version ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 05:57:34 2019 From: report at bugs.python.org (Michael Felt) Date: Fri, 02 Aug 2019 09:57:34 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1564739303.68.0.77764309603.issue18049@roundup.psfhosted.org> Message-ID: <4d7ec648-de38-168f-2f45-0878e93ab879@felt.demon.nl> Michael Felt added the comment: On 02/08/2019 11:48, Ronald Oussoren wrote: > Ronald Oussoren added the comment: > > That code is only called if THREAD_STACK_SIZE is defined. The block I mention defines it for macOS and FreeBSD, but not for other platforms. I therefore expect that this code is not used on AIX (which would be easy enough to verify by adding an #error to the block you mention. Should have been watching mail - I'll look at this asap. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 06:17:47 2019 From: report at bugs.python.org (Michael Felt) Date: Fri, 02 Aug 2019 10:17:47 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <4d7ec648-de38-168f-2f45-0878e93ab879@felt.demon.nl> Message-ID: Michael Felt added the comment: On 02/08/2019 11:57, Michael Felt wrote: > On 02/08/2019 11:48, Ronald Oussoren wrote: >> Ronald Oussoren added the comment: >> >> That code is only called if THREAD_STACK_SIZE is defined. The block I mention defines it for macOS and FreeBSD, but not for other platforms. I therefore expect that this code is not used on AIX (which would be easy enough to verify by adding an #error to the block you mention. > Should have been watching mail - I'll look at this asap. Actually, it is defined for "most" platforms... root at x066:[/data/prj/python/python3-3.9]make xlc_r -c? -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1???? -I../git/python3-3.9/Include/internal -IObjects -IInclude -IPython -I. -I../git/python3-3.9/Include -I/opt/include?? -DPy_BUILD_CORE -o Python/thread.o ../git/python3-3.9/Python/thread.c "../git/python3-3.9/Python/thread_pthread.h", line 255.2: 1506-205 (S) #error "Not expected" make: *** [Makefile:1706: Python/thread.o] Error 1 At the top of the file: /* The POSIX spec requires that use of pthread_attr_setstacksize ?? be conditional on _POSIX_THREAD_ATTR_STACKSIZE being defined. */ #ifdef _POSIX_THREAD_ATTR_STACKSIZE #ifndef THREAD_STACK_SIZE #define THREAD_STACK_SIZE?????? 0?????? /* use default stack size */ #endif /* The default stack size for new threads on OSX and BSD is small enough that ?* we'll get hard crashes instead of 'maximum recursion depth exceeded' ?* exceptions. ?* ?* The default stack sizes below are the empirically determined minimal stack ?* sizes where a simple recursive function doesn't cause a hard crash. ?*/ So, the block is executed - but the size is 0 aka default. As a first attempt - I'll take the FreeBSD size going: michael at x071:[/data/prj/python/git/python3-3.9]git diff diff --git a/Python/thread_pthread.h b/Python/thread_pthread.h index 994e35b..83b7e77 100644 --- a/Python/thread_pthread.h +++ b/Python/thread_pthread.h @@ -47,6 +47,10 @@ ?#undef? THREAD_STACK_SIZE ?#define THREAD_STACK_SIZE?????? 0x400000 ?#endif +#if defined(_AIX) && defined(THREAD_STACK_SIZE) && THREAD_STACK_SIZE == 0 +#undef? THREAD_STACK_SIZE +#define THREAD_STACK_SIZE?????? 0x400000 +#endif ?/* for safety, ensure a viable minimum stacksize */ ?#define THREAD_STACK_MIN??????? 0x8000? /* 32 KiB */ ?#else? /* !_POSIX_THREAD_ATTR_STACKSIZE */ And with this - the test passes. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 09:04:51 2019 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 02 Aug 2019 13:04:51 +0000 Subject: [issue37742] logging.getLogger accepts name='root' leading to confusion In-Reply-To: <1564701753.98.0.180548657893.issue37742@roundup.psfhosted.org> Message-ID: <1564751091.3.0.236550577802.issue37742@roundup.psfhosted.org> Change by Vinay Sajip : ---------- assignee: -> vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 09:05:26 2019 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 02 Aug 2019 13:05:26 +0000 Subject: [issue37742] logging.getLogger accepts name='root' leading to confusion In-Reply-To: <1564701753.98.0.180548657893.issue37742@roundup.psfhosted.org> Message-ID: <1564751126.63.0.352243701353.issue37742@roundup.psfhosted.org> Change by Vinay Sajip : ---------- keywords: +patch pull_requests: +14824 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15077 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 09:55:30 2019 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Eiras?=) Date: Fri, 02 Aug 2019 13:55:30 +0000 Subject: [issue29036] logging module: Add `full_module_name` to LogRecord details In-Reply-To: <1482336912.68.0.293105867979.issue29036@psf.upfronthosting.co.za> Message-ID: <1564754130.06.0.511575065782.issue29036@roundup.psfhosted.org> Jo?o Eiras added the comment: Hi. I ask for this to be reconsidered. The "recommended" approach of using "getLogger(__name__)" comes with some downsides. In my projects I often have many many files (in one particularly I have hundreds) and creating Logger object for each and every file, so LogRecord.name is correct is burdensome, litters the code and forces to add a global variable to the file. So, the easy approach we took was to use using logging.log(...) everywhere. I've also seen code elsewhere where it is not guaranteed that "getLogger(__name__)" is called with the module __name__, but with some other string. Or I've seen code where there is a shared Logger() created in some config.py that is then imported into other files. Overall, relying on LogRecord.name is error prone and requires adding more code. I checked the logging module. The findCaller() function could easily just poke frame.f_globals.get("__name__") to get the module name, and propagate that to the LogRecord. It's a simple addition. I can make a PR so you can comment further there. The name of the property would be LogRecord.fullModule. Thank you. ---------- nosy: +Jo?o Eiras _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 10:02:04 2019 From: report at bugs.python.org (Benjamin Wood) Date: Fri, 02 Aug 2019 14:02:04 +0000 Subject: [issue17254] add thai encoding aliases to encodings.aliases In-Reply-To: <1361360924.27.0.663240022367.issue17254@psf.upfronthosting.co.za> Message-ID: <1564754524.46.0.0359404995646.issue17254@roundup.psfhosted.org> Benjamin Wood added the comment: >From what I can tell cp874 != ibm_874 != iso_8859_11 What I can say is that the current cp874 is the implementation of the windows_874 code page. The page itself references the microsoft code page, and also contains the appropriate characters (like EURO SIGN). https://github.com/python/cpython/blob/master/Lib/encodings/cp874.py """ Python Character Mapping Codec cp874 generated from 'MAPPINGS/VENDORS/MICSFT/WINDOWS/CP874.TXT' with gencodec.py. https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP874.TXT It seems appropriate to at least alias windows_874 with cp874. They are provably the same. If someone needs the IBM standard, they may have to write a different code page. ---------- nosy: +Benjamin Wood _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 10:31:15 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Fri, 02 Aug 2019 14:31:15 +0000 Subject: [issue34488] improve performance of BytesIO.writelines() by avoiding creation of unused PyLongs In-Reply-To: <1535133350.73.0.56676864532.issue34488@psf.upfronthosting.co.za> Message-ID: <1564756275.37.0.361256729373.issue34488@roundup.psfhosted.org> Sergey Fedoseev added the comment: `BytesIO.write()` and `BytesIO.writelines()` are independent of each other. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 10:43:18 2019 From: report at bugs.python.org (Roundup Robot) Date: Fri, 02 Aug 2019 14:43:18 +0000 Subject: [issue17254] add thai encoding aliases to encodings.aliases In-Reply-To: <1361360924.27.0.663240022367.issue17254@psf.upfronthosting.co.za> Message-ID: <1564756998.51.0.684449272427.issue17254@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +14825 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15079 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 11:50:31 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 02 Aug 2019 15:50:31 +0000 Subject: [issue36487] Make C-API docs clear about what the "main" interpreter is In-Reply-To: <1553961350.55.0.679076430542.issue36487@roundup.psfhosted.org> Message-ID: <1564761031.17.0.251303933066.issue36487@roundup.psfhosted.org> Eric Snow added the comment: New changeset 854d0a4b98b13629252e21edaf2b785b429e5135 by Eric Snow (Joannah Nanjekye) in branch 'master': bpo-36487: Make C-API docs clear about what the main interpreter is. (gh-12666) https://github.com/python/cpython/commit/854d0a4b98b13629252e21edaf2b785b429e5135 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 11:53:04 2019 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 02 Aug 2019 15:53:04 +0000 Subject: [issue37742] logging.getLogger accepts name='root' leading to confusion In-Reply-To: <1564701753.98.0.180548657893.issue37742@roundup.psfhosted.org> Message-ID: <1564761184.97.0.581260958539.issue37742@roundup.psfhosted.org> Vinay Sajip added the comment: New changeset cb65b3a4f484ce71dcb76a918af98c7015513025 by Vinay Sajip in branch 'master': bpo-37742: Return the root logger when logging.getLogger('root') is c? (#15077) https://github.com/python/cpython/commit/cb65b3a4f484ce71dcb76a918af98c7015513025 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 11:54:28 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 02 Aug 2019 15:54:28 +0000 Subject: [issue36487] Make C-API docs clear about what the "main" interpreter is In-Reply-To: <1553961350.55.0.679076430542.issue36487@roundup.psfhosted.org> Message-ID: <1564761268.92.0.117151629605.issue36487@roundup.psfhosted.org> Eric Snow added the comment: Thanks, Joannah! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 11:55:11 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 15:55:11 +0000 Subject: [issue36487] Make C-API docs clear about what the "main" interpreter is In-Reply-To: <1553961350.55.0.679076430542.issue36487@roundup.psfhosted.org> Message-ID: <1564761311.0.0.916687112592.issue36487@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14826 pull_request: https://github.com/python/cpython/pull/15080 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 12:01:28 2019 From: report at bugs.python.org (Vinay Sajip) Date: Fri, 02 Aug 2019 16:01:28 +0000 Subject: [issue37742] logging.getLogger accepts name='root' leading to confusion In-Reply-To: <1564701753.98.0.180548657893.issue37742@roundup.psfhosted.org> Message-ID: <1564761688.45.0.447624243945.issue37742@roundup.psfhosted.org> Change by Vinay Sajip : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 13:01:39 2019 From: report at bugs.python.org (Michael Felt) Date: Fri, 02 Aug 2019 17:01:39 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564765299.93.0.609751292512.issue18049@roundup.psfhosted.org> Change by Michael Felt : ---------- pull_requests: +14827 pull_request: https://github.com/python/cpython/pull/15081 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 13:21:08 2019 From: report at bugs.python.org (Christopher Brousseau) Date: Fri, 02 Aug 2019 17:21:08 +0000 Subject: [issue37745] 3.8b3 - windows install gui/ inconsistent options Message-ID: <1564766468.14.0.320547199271.issue37745@roundup.psfhosted.org> New submission from Christopher Brousseau : When installing 3.8.0b3 64-bit into Win 10 using the gui following the `customize installation` path, there are duplicate and inconsistent options on three different screens for the `install for all users` checkbox. Observed Behavior: 1. first screen (Install Python) - `install launcher for all users` is marked as checked as default 2. second screen (Optional Features) - 2.1 `for all users` is also marked as checked if first screen marked. if second screen marked - this is unchecked. 2.2 layout of this checkbox is above a comment that relates only to the "py launcher" checkbox. would be more clear for user if `for all users` was located below "py launcher", or removed from this screen (per note below) 3. third screen (Advanced Options) - `Install for all users` is UNchecked in all cases, even if first & second screens are checked. Expected Behavior: 1. if first screen is checked, all follow on screens are also checked 2. feature options only appear on one screen, or at a minimum, checkbox label is exactly the same on all screens Additional Questions for the team: 1. Should all install customizations be removed from first screen, set as default options and just listed as descriptions under the `Install Now` default? 2. Should `for all users` option be removed from the 2nd screen (Optional Features)? It seems more like an "advanced option" than a feature. Screenshots (this site appears to only allow one file) first: https://imgur.com/a/0a45CBh second: https://imgur.com/a/6ZV16bV third: https://imgur.com/a/stRTh25 Link to binary used for this: https://www.python.org/ftp/python/3.8.0/python-3.8.0b3-amd64.exe ---------- components: Installation, Windows files: python_3.8b3_screen02_optional_features_2019-08-02_9-56-02.png messages: 348907 nosy: Christopher Brousseau, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: 3.8b3 - windows install gui/ inconsistent options type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file48527/python_3.8b3_screen02_optional_features_2019-08-02_9-56-02.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 13:23:17 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 17:23:17 +0000 Subject: [issue37746] Provide Windows predefined access type constants Message-ID: <1564766597.45.0.90249654152.issue37746@roundup.psfhosted.org> New submission from Steve Dower : We currently do not provide the standard access type constants anywhere, despite providing some of the specific access type flags (e.g. in `winreg`): #define DELETE (0x00010000L) #define READ_CONTROL (0x00020000L) #define WRITE_DAC (0x00040000L) #define WRITE_OWNER (0x00080000L) #define SYNCHRONIZE (0x00100000L) #define STANDARD_RIGHTS_REQUIRED (0x000F0000L) #define STANDARD_RIGHTS_READ (READ_CONTROL) #define STANDARD_RIGHTS_WRITE (READ_CONTROL) #define STANDARD_RIGHTS_EXECUTE (READ_CONTROL) #define STANDARD_RIGHTS_ALL (0x001F0000L) #define SPECIFIC_RIGHTS_ALL (0x0000FFFFL) I'm not sure where the best place to expose them would be. `os` (`nt`) seems best, but it's 99% a POSIX shim that doesn't actually have anything Windows-specific exposed, and `_winapi` is not public. They're likely already available through pywin32 or similar, but given their use with `winreg` we should probably at least make them available there. ---------- components: Windows messages: 348908 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Provide Windows predefined access type constants type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 13:49:41 2019 From: report at bugs.python.org (Eric Snow) Date: Fri, 02 Aug 2019 17:49:41 +0000 Subject: [issue36487] Make C-API docs clear about what the "main" interpreter is In-Reply-To: <1553961350.55.0.679076430542.issue36487@roundup.psfhosted.org> Message-ID: <1564768181.5.0.85311972964.issue36487@roundup.psfhosted.org> Eric Snow added the comment: New changeset 375f35be0688da0fc0f27afc4faea76590d7c24d by Eric Snow (Miss Islington (bot)) in branch '3.8': bpo-36487: Make C-API docs clear about what the main interpreter is. (gh-15080) https://github.com/python/cpython/commit/375f35be0688da0fc0f27afc4faea76590d7c24d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 14:38:27 2019 From: report at bugs.python.org (bp256r1) Date: Fri, 02 Aug 2019 18:38:27 +0000 Subject: [issue37747] _markupbase.py fails with TypeError on invalid keyword in marked section Message-ID: <1564771107.73.0.664658859343.issue37747@roundup.psfhosted.org> New submission from bp256r1 : Hello, I'm not sure if this a bug, but I noticed that a TypeError is raised by the parse_marked_section function of the _markupbase module in Python 3.7.4 when attempting to parse a name token of >> a='>> from bs4 import BeautifulSoup >>> BeautifulSoup(a, 'html.parser') /usr/local/lib/python3.7/site-packages/bs4/builder/_htmlparser.py:78: UserWarning: expected name token at '", line 1, in File "/usr/local/lib/python3.7/site-packages/bs4/__init__.py", line 303, in __init__ self._feed() File "/usr/local/lib/python3.7/site-packages/bs4/__init__.py", line 364, in _feed self.builder.feed(self.markup) File "/usr/local/lib/python3.7/site-packages/bs4/builder/_htmlparser.py", line 250, in feed parser.feed(markup) File "/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/html/parser.py", line 111, in feed self.goahead(0) File "/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/html/parser.py", line 179, in goahead k = self.parse_html_declaration(i) File "/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/html/parser.py", line 264, in parse_html_declaration return self.parse_marked_section(i) File "/usr/local/Cellar/python/3.7.4/Frameworks/Python.framework/Versions/3.7/lib/python3.7/_markupbase.py", line 149, in parse_marked_section sectName, j = self._scan_name( i+3, i ) TypeError: cannot unpack non-iterable NoneType object If it's not a bug, sorry, not sure. ---------- components: Library (Lib) messages: 348910 nosy: berker.peksag, bp256r1, ezio.melotti, kodial priority: normal severity: normal status: open title: _markupbase.py fails with TypeError on invalid keyword in marked section versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 15:19:58 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 19:19:58 +0000 Subject: [issue37745] 3.8b3 - windows install gui/ inconsistent options In-Reply-To: <1564766468.14.0.320547199271.issue37745@roundup.psfhosted.org> Message-ID: <1564773598.17.0.93944224442.issue37745@roundup.psfhosted.org> Steve Dower added the comment: The "for all users" checkbox you refer to only applies to the launcher, which is why it is immediately alongside the option to install the launcher (and above the comment about the launcher). The "Install for all users" option on the final page is for the Python runtime (and if selected, also the launcher). So the only duplication is the "launcher for all users" checkbox on the front page, and that's there so that people who use the default options are able to easily disable it if they don't have administrative privileges. (Also, everything on the front page is a duplicate of something else :) ) I'd happily accept an alternative design for the launcher options if it doesn't involve making the window larger and only uses checkboxes (we have fairly limited UI options available in this installer framework). Or maybe there's a simple text update we can make? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 15:57:51 2019 From: report at bugs.python.org (Tal Einat) Date: Fri, 02 Aug 2019 19:57:51 +0000 Subject: [issue37724] [[Errno 17] File exists: ] # Try create directories that are not part of the archive with In-Reply-To: <1564525622.36.0.964910267569.issue37724@roundup.psfhosted.org> Message-ID: <1564775871.85.0.49295879687.issue37724@roundup.psfhosted.org> Tal Einat added the comment: Hi Tal, could you please make your report clearer by giving more context? Right now it is very hard to understand. The following would be helpful: * What are you trying to do that is failing? (perhaps extract a Zip archive?) * Which libraries/classes/functions are you using? * Can you provide a small sample of code which we can use to reproduce this error ourselves? ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 15:59:56 2019 From: report at bugs.python.org (Tal Einat) Date: Fri, 02 Aug 2019 19:59:56 +0000 Subject: [issue37733] Fail to build _curses module of Python 3.7.4 on AIX 7.1 using gcc In-Reply-To: <1564585726.95.0.247783534499.issue37733@roundup.psfhosted.org> Message-ID: <1564775996.51.0.672322693279.issue37733@roundup.psfhosted.org> Change by Tal Einat : ---------- nosy: +Michael.Felt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 16:16:43 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 20:16:43 +0000 Subject: [issue36678] duplicate method definitions in Lib/test/test_dataclasses.py In-Reply-To: <1555775728.19.0.814114535778.issue36678@roundup.psfhosted.org> Message-ID: <1564777003.56.0.884493232038.issue36678@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 16:16:53 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 20:16:53 +0000 Subject: [issue36680] duplicate method definition in Lib/test/test_importlib/test_util.py In-Reply-To: <1555776149.55.0.853112327072.issue36680@roundup.psfhosted.org> Message-ID: <1564777013.18.0.314663718808.issue36680@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 16:17:05 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 20:17:05 +0000 Subject: [issue36681] duplicate method definition in Lib/test/test_logging.py In-Reply-To: <1555776283.44.0.382290590702.issue36681@roundup.psfhosted.org> Message-ID: <1564777025.24.0.978427419474.issue36681@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 16:17:17 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 20:17:17 +0000 Subject: [issue36683] duplicate method definition in Lib/test/test_utf8_mode.py In-Reply-To: <1555776614.31.0.832242060156.issue36683@roundup.psfhosted.org> Message-ID: <1564777037.85.0.475548676407.issue36683@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 16:25:27 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 20:25:27 +0000 Subject: [issue33408] Enable AF_UNIX support in Windows In-Reply-To: <1525257332.06.0.682650639539.issue33408@psf.upfronthosting.co.za> Message-ID: <1564777527.56.0.406426137454.issue33408@roundup.psfhosted.org> Steve Dower added the comment: Most of those examples would break today if run on Windows, though (AttributeError). So they'd just continue to break, probably with a different error (I'm not clear what happens if we specify SOCK_DGRAM with this change). Having an undocumented field doesn't really help much - what we want is a documented field with a different name, perhaps WIN_AF_UNIX? (I think we need to keep the "AF_" prefix for real values and not mess up the namespace ourselves.) That way we can document that it matches AF_UNIX when defined on Windows, but will not trigger existing code that checks for the presence of AF_UNIX. Then we'll have to update the standard library to use either/both values where supported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 16:30:01 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 20:30:01 +0000 Subject: [issue36590] Add Bluetooth RFCOMM Support for Windows In-Reply-To: <1554927671.26.0.0558973169259.issue36590@roundup.psfhosted.org> Message-ID: <1564777801.22.0.896444450236.issue36590@roundup.psfhosted.org> Steve Dower added the comment: New changeset 8fbece135d7615e836a845ca39223097046c8b8b by Steve Dower (Greg Bowser) in branch 'master': bpo-36590: Add Bluetooth RFCOMM and support for Windows. (GH-12767) https://github.com/python/cpython/commit/8fbece135d7615e836a845ca39223097046c8b8b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 16:30:19 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 20:30:19 +0000 Subject: [issue36590] Add Bluetooth RFCOMM Support for Windows In-Reply-To: <1554927671.26.0.0558973169259.issue36590@roundup.psfhosted.org> Message-ID: <1564777819.65.0.0546907110083.issue36590@roundup.psfhosted.org> Steve Dower added the comment: Thanks for the patch! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 16:42:58 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 20:42:58 +0000 Subject: [issue31226] shutil.rmtree fails when target has an internal directory junction (Windows) In-Reply-To: <1502978298.87.0.60982184572.issue31226@psf.upfronthosting.co.za> Message-ID: <1564778578.69.0.100956264698.issue31226@roundup.psfhosted.org> Steve Dower added the comment: Sorry for being slow to review, I just added a few more comments on the PR and I think we're nearly done. ---------- versions: +Python 3.9 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 16:46:39 2019 From: report at bugs.python.org (Michael Felt) Date: Fri, 02 Aug 2019 20:46:39 +0000 Subject: [issue37733] Fail to build _curses module of Python 3.7.4 on AIX 7.1 using gcc In-Reply-To: <1564585726.95.0.247783534499.issue37733@roundup.psfhosted.org> Message-ID: <1564778799.19.0.776071692906.issue37733@roundup.psfhosted.org> Michael Felt added the comment: Issue36210 needs a back-port to 3.7 and 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 16:47:27 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 20:47:27 +0000 Subject: [issue36557] Python (Launcher)3.7.3 CMDLine install/uninstall In-Reply-To: <1554726023.31.0.350138244198.issue36557@roundup.psfhosted.org> Message-ID: <1564778847.53.0.224952562489.issue36557@roundup.psfhosted.org> Steve Dower added the comment: Sorry for the slow reply. > immediately begin removing Python - no prompt will be displayed This is meant to imply that no *confirmation* prompt will be displayed before uninstall starts. Documentation patches are welcome :) > tell me something about passive The /passive option means the user can see progress and (if appropriate), cancel the operation, but otherwise does not have to interact with it at all. This is good for semi-interactive scripts, where the user starts it and wants to see what's happening, but could also walk away and let it run to completion. With /quiet, there'd be no progress or errors (generally /passive will stop and wait if an error occurs), and without either the success page would also stop and wait. These are fairly typical command line options for installers on Windows, and the Python installer users them in the standard way. Mostly because we haven't done anything to customize them from the installer toolkit we use :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 17:03:38 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 02 Aug 2019 21:03:38 +0000 Subject: [issue37746] Provide Windows predefined access type constants In-Reply-To: <1564766597.45.0.90249654152.issue37746@roundup.psfhosted.org> Message-ID: <1564779818.5.0.792639086919.issue37746@roundup.psfhosted.org> Eryk Sun added the comment: The STANDARD_RIGHTS_* and SPECIFIC_RIGHTS_ALL constants aren't used much in practice. Do you have a particular case that needs them? I don't think we have direct use for the standard rights constants in winreg. For example, deleting a key via winreg.DeleteKeyEx internally opens a handle with the required DELETE access. Also, kernel key objects don't even support SYNCHRONIZE access (i.e. they can't be waited on). There's also the generic rights that object types map to sets of standard and specific rights: GENERIC_READ (0x8000_0000), GENERIC_WRITE (0x4000_0000), GENERIC_EXECUTE (0x2000_0000), and GENERIC_ALL (0x1000_0000). But, here again, winreg doesn't really need this. It already includes the pre-mapped generic key rights: KEY_READ, KEY_WRITE, KEY_EXECUTE, and KEY_ALL_ACCESS (except GENERIC_EXECUTE actually maps to KEY_EXECUTE | KEY_CREATE_LINK). ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 17:05:02 2019 From: report at bugs.python.org (Daniel Lepage) Date: Fri, 02 Aug 2019 21:05:02 +0000 Subject: [issue36077] Inheritance dataclasses fields and default init statement In-Reply-To: <1550838433.8.0.658564691536.issue36077@roundup.psfhosted.org> Message-ID: <1564779902.71.0.667212438477.issue36077@roundup.psfhosted.org> Daniel Lepage added the comment: A simpler way to merge them would be to make all arguments after a default argument keyword-only, e.g. __index__(self, i, j=0, *, k, l=0) It does mean you'd have to explicitly write e.g. Child(1, k=4), but that's a lot more readable than seeing Child(1, 4) and wondering which field gets the 4. ---------- nosy: +Daniel Lepage2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 17:34:20 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 21:34:20 +0000 Subject: [issue36311] Flaw in Windows code page decoder for large input In-Reply-To: <1552723600.79.0.686719955113.issue36311@roundup.psfhosted.org> Message-ID: <1564781660.58.0.735421605814.issue36311@roundup.psfhosted.org> Steve Dower added the comment: If we reduce our chunk size below INT_MAX, then we avoid the issue entirely. Our logic for hitting the middle of a multibyte character is fine (perhaps fixed since this issue was opened?), there's just a weird edge case at 2 GiB in the API call. As a bonus, smaller chunks seems to have a performance benefit too. It seems like INT_MAX/4 is the sweet spot - it took about a quarter of the time for my 2GiB test case as INT_MAX (and we're measuring in tens of seconds here, so I'm pretty comfortable with the direction of the result). INT_MAX/2 and INT_MAX/8 were both slower than INT_MAX/4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 17:58:26 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 21:58:26 +0000 Subject: [issue36311] Flaw in Windows code page decoder for large input In-Reply-To: <1552723600.79.0.686719955113.issue36311@roundup.psfhosted.org> Message-ID: <1564783106.16.0.660747043456.issue36311@roundup.psfhosted.org> Change by Steve Dower : ---------- assignee: -> steve.dower versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:04:07 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:04:07 +0000 Subject: [issue36311] Flaw in Windows code page decoder for large input In-Reply-To: <1552723600.79.0.686719955113.issue36311@roundup.psfhosted.org> Message-ID: <1564783447.73.0.962890896209.issue36311@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch pull_requests: +14828 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/15083 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:05:28 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:05:28 +0000 Subject: [issue36394] test_multiprocessing_spawn fails on Windows7 3.x buildbot In-Reply-To: <1553212800.6.0.577626809439.issue36394@roundup.psfhosted.org> Message-ID: <1564783528.11.0.705198911015.issue36394@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:06:03 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:06:03 +0000 Subject: [issue20391] windows python launcher should support explicit 64-bit version In-Reply-To: <1390666697.34.0.8179359034.issue20391@psf.upfronthosting.co.za> Message-ID: <1564783563.08.0.0979853755876.issue20391@roundup.psfhosted.org> Steve Dower added the comment: This has been implemented. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:11:28 2019 From: report at bugs.python.org (Brett Cannon) Date: Fri, 02 Aug 2019 22:11:28 +0000 Subject: [issue37409] relative import without parent succeeds with builtins.__import__ In-Reply-To: <1561540286.77.0.471225789226.issue37409@roundup.psfhosted.org> Message-ID: <1564783888.87.0.613866990527.issue37409@roundup.psfhosted.org> Change by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:17:33 2019 From: report at bugs.python.org (Paul Monson) Date: Fri, 02 Aug 2019 22:17:33 +0000 Subject: [issue33408] Enable AF_UNIX support in Windows In-Reply-To: <1525257332.06.0.682650639539.issue33408@psf.upfronthosting.co.za> Message-ID: <1564784253.83.0.303620594598.issue33408@roundup.psfhosted.org> Paul Monson added the comment: If you try to create a datagram socket with the current AF_UNIX changes on Windows the error is: OSError: [WinError 10047] An address incompatible with the requested protocol was used All of the examples given will fail to load with AttributeError on Windows because socket.AF_UNIX is not a valid attribute on Windows. I think it's possible that there is code that detects whether AF_UNIX is an attribute on socket or not and does something different on Windows, but I haven't seen an example of it so far. I can make the changes to WIN_AF_UNIX when I continue working on this, just in case there is portable code out there somewhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:19:42 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:19:42 +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: <1564784382.7.0.298159323722.issue20523@roundup.psfhosted.org> Change by Steve Dower : ---------- versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:20:17 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:20: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: <1564784417.76.0.956539171451.issue20523@roundup.psfhosted.org> Steve Dower added the comment: New changeset 7ea9a85f132b32347fcbd2cbe1b553a2e9890b56 by Steve Dower (Timothy Hopper) in branch 'master': bpo-20523: pdb searches for .pdbrc in ~ instead of $HOME (GH-11847) https://github.com/python/cpython/commit/7ea9a85f132b32347fcbd2cbe1b553a2e9890b56 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:20:33 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 22:20:33 +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: <1564784433.71.0.268872227535.issue20523@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14829 pull_request: https://github.com/python/cpython/pull/15084 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:20:53 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 22:20:53 +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: <1564784453.69.0.0587179235641.issue20523@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14830 pull_request: https://github.com/python/cpython/pull/15085 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:25:07 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:25:07 +0000 Subject: [issue32326] Update Build projects to version 10.0.16299.0 of the Windows 10 SDK. In-Reply-To: <1513283155.41.0.213398074469.issue32326@psf.upfronthosting.co.za> Message-ID: <1564784707.89.0.844780521499.issue32326@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:25:29 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:25:29 +0000 Subject: [issue23451] Deprecation warnings building 3.5 Visual Studio Windows 8.1 64 bit In-Reply-To: <1423697646.35.0.470486317043.issue23451@psf.upfronthosting.co.za> Message-ID: <1564784729.29.0.34155496682.issue23451@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:25:50 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:25:50 +0000 Subject: [issue5438] test_bigmem.test_from_2G_generator uses more memory than expected In-Reply-To: <1236475515.92.0.849329057425.issue5438@psf.upfronthosting.co.za> Message-ID: <1564784750.89.0.654844316349.issue5438@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:26:41 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:26:41 +0000 Subject: [issue33779] Error while installing python 3.6.5 on windows 10 In-Reply-To: <1528277897.55.0.592728768989.issue33779@psf.upfronthosting.co.za> Message-ID: <1564784801.42.0.0969425101074.issue33779@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:30:35 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:30:35 +0000 Subject: [issue35058] Unable to Install Python on Windows In-Reply-To: <1540390509.38.0.788709270274.issue35058@psf.upfronthosting.co.za> Message-ID: <1564785035.29.0.128567114736.issue35058@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:31:19 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:31:19 +0000 Subject: [issue34562] cannot install versions 3.6.5+ on Windows In-Reply-To: <1535796351.86.0.56676864532.issue34562@psf.upfronthosting.co.za> Message-ID: <1564785079.96.0.34423022597.issue34562@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:36:47 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:36:47 +0000 Subject: [issue21983] segfault in ctypes.cast In-Reply-To: <1405374806.18.0.56272254378.issue21983@psf.upfronthosting.co.za> Message-ID: <1564785407.29.0.276751987238.issue21983@roundup.psfhosted.org> Change by Steve Dower : ---------- assignee: steve.dower -> stage: patch review -> backport needed versions: -Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:39:24 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:39:24 +0000 Subject: [issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args In-Reply-To: <1509989245.86.0.213398074469.issue31961@psf.upfronthosting.co.za> Message-ID: <1564785564.65.0.537438490463.issue31961@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:39:40 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:39:40 +0000 Subject: [issue33617] subprocess.Popen etc do not accept os.PathLike in passed sequence on Windows In-Reply-To: <1527084844.2.0.682650639539.issue33617@psf.upfronthosting.co.za> Message-ID: <1564785580.62.0.045848741404.issue33617@roundup.psfhosted.org> Change by Steve Dower : ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:40:18 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 22:40:18 +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: <1564785618.22.0.0407079723481.issue20523@roundup.psfhosted.org> miss-islington added the comment: New changeset 1ff7dd681c7f3e31524bfada6d6d2786d4e37704 by Miss Islington (bot) in branch '3.7': bpo-20523: pdb searches for .pdbrc in ~ instead of $HOME (GH-11847) https://github.com/python/cpython/commit/1ff7dd681c7f3e31524bfada6d6d2786d4e37704 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:41:19 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:41:19 +0000 Subject: [issue34564] Tutorial Section 2.1 Windows Installation Path Correction In-Reply-To: <1535912620.22.0.56676864532.issue34564@psf.upfronthosting.co.za> Message-ID: <1564785679.65.0.139742963128.issue34564@roundup.psfhosted.org> Steve Dower added the comment: I updated this section in a separate issue. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:41:50 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:41:50 +0000 Subject: [issue34470] windows msi in headless mode fails to install Script directory on reinstall if the python folder was deleted but not uninstalled In-Reply-To: <1534996213.68.0.56676864532.issue34470@psf.upfronthosting.co.za> Message-ID: <1564785710.98.0.511100196226.issue34470@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:42:53 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 22:42:53 +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: <1564785773.91.0.730725071518.issue20523@roundup.psfhosted.org> miss-islington added the comment: New changeset 79af3bd1d170ed6a72a5c126e862590cdbf192d7 by Miss Islington (bot) in branch '3.8': bpo-20523: pdb searches for .pdbrc in ~ instead of $HOME (GH-11847) https://github.com/python/cpython/commit/79af3bd1d170ed6a72a5c126e862590cdbf192d7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:44:27 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:44:27 +0000 Subject: [issue30974] Update os.samefile docstring to match documentation In-Reply-To: <1500538030.77.0.17785692497.issue30974@psf.upfronthosting.co.za> Message-ID: <1564785867.83.0.447495926342.issue30974@roundup.psfhosted.org> Steve Dower added the comment: New changeset 8e568ef266a2805f9a6042003723d9c050830461 by Steve Dower (Timo Furrer) in branch 'master': bpo-30974: Change os.path.samefile docstring to match docs (GH-7337) https://github.com/python/cpython/commit/8e568ef266a2805f9a6042003723d9c050830461 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:44:51 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 22:44:51 +0000 Subject: [issue30974] Update os.samefile docstring to match documentation In-Reply-To: <1500538030.77.0.17785692497.issue30974@psf.upfronthosting.co.za> Message-ID: <1564785891.72.0.920888441668.issue30974@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14831 pull_request: https://github.com/python/cpython/pull/15086 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:44:57 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 22:44:57 +0000 Subject: [issue30974] Update os.samefile docstring to match documentation In-Reply-To: <1500538030.77.0.17785692497.issue30974@psf.upfronthosting.co.za> Message-ID: <1564785897.43.0.00321148762572.issue30974@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14832 pull_request: https://github.com/python/cpython/pull/15087 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:46:09 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:46:09 +0000 Subject: [issue30974] Update os.samefile docstring to match documentation In-Reply-To: <1500538030.77.0.17785692497.issue30974@psf.upfronthosting.co.za> Message-ID: <1564785969.28.0.615226064301.issue30974@roundup.psfhosted.org> Steve Dower added the comment: I'm not personally thrilled about it being documented like this, but it's certainly how the current documentation reads. Consistency is better until we get motivated enough to fix all of it. Thanks for the patch! ---------- stage: patch review -> backport needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:46:38 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:46:38 +0000 Subject: [issue30974] Update os.samefile docstring to match documentation In-Reply-To: <1500538030.77.0.17785692497.issue30974@psf.upfronthosting.co.za> Message-ID: <1564785998.4.0.690221695858.issue30974@roundup.psfhosted.org> Steve Dower added the comment: Still needs a 2.7 backport if someone would like to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:47:01 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:47:01 +0000 Subject: [issue31534] python 3.6.2 installation failed 0x80070002 error In-Reply-To: <1505923189.21.0.0271351675112.issue31534@psf.upfronthosting.co.za> Message-ID: <1564786021.19.0.390800272144.issue31534@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:47:32 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:47:32 +0000 Subject: [issue34142] Windows launcher version lookup flawed In-Reply-To: <1531879775.21.0.56676864532.issue34142@psf.upfronthosting.co.za> Message-ID: <1564786052.86.0.627558797369.issue34142@roundup.psfhosted.org> Change by Steve Dower : ---------- versions: +Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:48:39 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:48:39 +0000 Subject: [issue1327594] Static Windows Build fails to locate existing installation Message-ID: <1564786119.04.0.723045300207.issue1327594@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> out of date stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:53:43 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:53:43 +0000 Subject: [issue34232] Python3.7.0 exe installers (32 and 64 bit) failing on Windows7 In-Reply-To: <1532600152.06.0.56676864532.issue34232@psf.upfronthosting.co.za> Message-ID: <1564786423.17.0.0672918865902.issue34232@roundup.psfhosted.org> Steve Dower added the comment: Sorry about forgetting this - this is an issue with certain security configurations where variables are not passed across the Administrator boundary properly (and the subinstallers are automatically elevated to Administrator). If you right click the installer and choose "Run as Administrator" and then do the install it should be fine. ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 18:59:04 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 22:59:04 +0000 Subject: [issue33220] Antivirus hits on python-2.7.14.amd64.msi file In-Reply-To: <1522794242.81.0.467229070634.issue33220@psf.upfronthosting.co.za> Message-ID: <1564786744.44.0.637610472307.issue33220@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 19:00:25 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 23:00:25 +0000 Subject: [issue34026] Request for 2 Windows installation changes. In-Reply-To: <1530554998.5.0.56676864532.issue34026@psf.upfronthosting.co.za> Message-ID: <1564786825.19.0.678786255416.issue34026@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> wont fix stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 19:04:57 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 23:04:57 +0000 Subject: [issue30974] Update os.samefile docstring to match documentation In-Reply-To: <1500538030.77.0.17785692497.issue30974@psf.upfronthosting.co.za> Message-ID: <1564787097.13.0.898950557143.issue30974@roundup.psfhosted.org> miss-islington added the comment: New changeset 6b833901fe9053937c289c6371bb731c9aceb58e by Miss Islington (bot) in branch '3.8': bpo-30974: Change os.path.samefile docstring to match docs (GH-7337) https://github.com/python/cpython/commit/6b833901fe9053937c289c6371bb731c9aceb58e ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 19:11:36 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 02 Aug 2019 23:11:36 +0000 Subject: [issue30974] Update os.samefile docstring to match documentation In-Reply-To: <1500538030.77.0.17785692497.issue30974@psf.upfronthosting.co.za> Message-ID: <1564787496.77.0.394356330158.issue30974@roundup.psfhosted.org> miss-islington added the comment: New changeset a49f203e052c6fb1244d4e55c3fccc439dda0e2e by Miss Islington (bot) in branch '3.7': bpo-30974: Change os.path.samefile docstring to match docs (GH-7337) https://github.com/python/cpython/commit/a49f203e052c6fb1244d4e55c3fccc439dda0e2e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 19:14:19 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 23:14:19 +0000 Subject: [issue31612] Building 3.6 fails on Windows In-Reply-To: <1506520522.86.0.154975027568.issue31612@psf.upfronthosting.co.za> Message-ID: <1564787659.51.0.0683075599922.issue31612@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 19:15:33 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 23:15:33 +0000 Subject: [issue31476] Stdlib source files not installed In-Reply-To: <1505418617.55.0.339159278979.issue31476@psf.upfronthosting.co.za> Message-ID: <1564787733.99.0.451636850496.issue31476@roundup.psfhosted.org> Steve Dower added the comment: Closing this as out of date, but if you're still watching Zero, make sure you aren't browsing the __pycache__ directory instead of the source directories. We definitely ship sources with all of our distributions. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 19:25:16 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 02 Aug 2019 23:25:16 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1564788316.52.0.541666811226.issue25172@roundup.psfhosted.org> Steve Dower added the comment: Marking this easy/newcomer friendly. This should catch the ModuleNotFoundError raised when _crypt is missing and raise a more informative ImportError saying that crypt is unsupported. All the other modules that are missing are native extension modules that are not built - this is the only one that is a .py file. We don't exclude any other Lib\*.py files from the distribution. ---------- keywords: +easy, newcomer friendly versions: +Python 3.8, Python 3.9 -Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 20:53:28 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 03 Aug 2019 00:53:28 +0000 Subject: [issue33408] Enable AF_UNIX support in Windows In-Reply-To: <1525257332.06.0.682650639539.issue33408@psf.upfronthosting.co.za> Message-ID: <1564793608.88.0.630398354108.issue33408@roundup.psfhosted.org> Steve Dower added the comment: > I think it's possible that there is code that detects whether AF_UNIX is an attribute on socket or not and does something different on Windows, but I haven't seen an example of it so far. One of the test suites linked above had a skipUnless(hasattr(socket, 'AF_UNIX')) on the whole class, and at least one test assumed that it could use datagram support, so there's the example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 21:03:36 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 03 Aug 2019 01:03:36 +0000 Subject: [issue37746] Provide Windows predefined access type constants In-Reply-To: <1564766597.45.0.90249654152.issue37746@roundup.psfhosted.org> Message-ID: <1564794216.81.0.510051082217.issue37746@roundup.psfhosted.org> Steve Dower added the comment: At least the first five can be used to open keys with even less rights than default, which can sometimes be necessary for keys with obscure ACLs. Having the constants present is also helpful when rendering a text view. Perhaps _winapi is the best place? It already includes CreateFile and OpenProcess, both of which also use these flags and already have some of the "preconstructed" values exposed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 23:07:43 2019 From: report at bugs.python.org (Aaron Meurer) Date: Sat, 03 Aug 2019 03:07:43 +0000 Subject: [issue37433] syntax error in multiline f-string produces ~40k spaces output In-Reply-To: <1561659761.86.0.416757939602.issue37433@roundup.psfhosted.org> Message-ID: <1564801663.56.0.364677103857.issue37433@roundup.psfhosted.org> Aaron Meurer added the comment: This seems related. It's also possible I'm misunderstanding what is supposed to happen here. If you create test.py with just the 2 lines: """ a and run python test.py from CPython master, you get $./python.exe test.py File "/Users/aaronmeurer/Documents/cpython/test.py", line 4 a ^ SyntaxError: EOF while scanning triple-quoted string literal Notice that it reports line 4 even though the file only has 2 lines. The offset in the syntax error is 6 columns (line numbers and column offsets in SyntaxErrors count from 1) >>> try: ... compile('"""\na', '', 'exec') ... except SyntaxError as e: ... print(repr(e)) ... SyntaxError('EOF while scanning triple-quoted string literal', ('', 2, 6, '"""\na\n')) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 2 23:31:56 2019 From: report at bugs.python.org (Eryk Sun) Date: Sat, 03 Aug 2019 03:31:56 +0000 Subject: [issue37746] Provide Windows predefined access type constants In-Reply-To: <1564766597.45.0.90249654152.issue37746@roundup.psfhosted.org> Message-ID: <1564803116.01.0.143477708085.issue37746@roundup.psfhosted.org> Eryk Sun added the comment: > Perhaps _winapi is the best place? It already includes CreateFile and > OpenProcess, both of which also use these flags and already have some > of the "preconstructed" values exposed. I'd like to see an os.windows namespace, with os.windows.constants and os.windows.errors. _winapi is for internal use. Some of what's defined there can be made public, including common constants and errors, but not all of it. > At least the first five can be used to open keys with even less rights > than default, which can sometimes be necessary for keys with obscure > ACLs. Key objects don't support SYNCHRONIZE. The only concern for us is excluding the other standard rights (i.e. READ_CONTROL, WRITE_OWNER, WRITE_DAC, DELETE). All four modes of generic access include READ_CONTROL, which allows querying an object's owner, group, and DACL, but we have no direct use of this information in winreg. KEY_ALL_ACCESS also includes WRITE_OWNER, WRITE_DAC and DELETE access, of which we also have no need. For deleting a key, DeleteKey[Ex] does not require DELETE access on the supplied handle, which is used by WINAPI RegDeleteKey[Ex]W only for an internal handle-relative open that requests DELETE access. The other two are also never needed directly by winreg, since it doesn't support security functions to modify the owner/group and DACL in a key's security descriptor. They're only of use indirectly if using ctypes or PyWin32 to call a handle-based security function such as SetSecurityInfo. If we can't get generic access because we lack one or more of the standard rights or specific rights in the generic set, then we can request just the required specific rights. The specific rights of the four generic access modes are as follows: KEY_READ : KEY_QUERY_VALUE, KEY_ENUMERATE_SUB_KEYS, KEY_NOTIFY KEY_WRITE : KEY_SET_VALUE, KEY_CREATE_SUB_KEY KEY_EXECUTE : Same as KEY_READ KEY_ALL_ACCESS: KEY_QUERY_VALUE, KEY_SET_VALUE, KEY_CREATE_SUB_KEY, KEY_ENUMERATE_SUB_KEYS, KEY_NOTIFY, KEY_CREATE_LINK ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 00:48:25 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 03 Aug 2019 04:48:25 +0000 Subject: [issue37748] IDLE: Re-order run menu Message-ID: <1564807705.24.0.436490903651.issue37748@roundup.psfhosted.org> New submission from Terry J. Reedy : With the addition of Run Customized, the run menu looks like Python Shell Check Module Run Module Run... Customized This order resulted from Check and Run Module originally being implemented as extensions, which forced them to be below Python Shell. The situation was similar with Format Paragraph being forced below less commonly used options on the Format menu. It is now at the top. Run... Customized was tacked on below, without worrying about the appropriate order for the menu.. On issue #37627, Raymond Hettinger suggested "Move the [new] menu option up by one so that the regular F5 "run" is last -- learners we having a hard time finding and mouse targeting the more commonly used regular "run" option. The result would be Python Shell Check Module Run... Customized Run Module I would rather make Run Module, the most commonly used option even more prominent by putting it at the top, perhaps by reversing the order. Run Module Run... Customized Check Module Python Shell With Run Module at the top, remaining items could be ordered by logic, and to me, the above is plausible on that score, or by use, perhaps putting the second-most used at the bottom. I suspect that this will be Run Customized. To me, Check Module is useless, though I can imagine situation when it is not. Python Shell is only needed when there is no shell and one does not want to make one appear by running a module. To switch to an existing Shell, on should use the Windows menu. Anyway, another candidate is Run Module Check Module Python Shell Run... Customized ---------- messages: 348940 nosy: cheryl.sabella, rhettinger, taleinat, terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE: Re-order run menu type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 00:52:50 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 03 Aug 2019 04:52:50 +0000 Subject: [issue37627] IDLE: populate Run Customized arguments with previous entry In-Reply-To: <1563521211.07.0.510212499932.issue37627@roundup.psfhosted.org> Message-ID: <1564807970.74.0.0146805875409.issue37627@roundup.psfhosted.org> Terry J. Reedy added the comment: This issues fixed item 2 above. Re-ordering the Run menu is #37748 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed superseder: -> IDLE: Re-order run menu title: Minor improvements to IDLE's "Run Customized" -> IDLE: populate Run Customized arguments with previous entry type: -> enhancement versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 01:16:46 2019 From: report at bugs.python.org (Brandon James) Date: Sat, 03 Aug 2019 05:16:46 +0000 Subject: [issue37749] ipaddress - is_global method all multicast addresses and networks return true Message-ID: <1564809406.61.0.356559045946.issue37749@roundup.psfhosted.org> New submission from Brandon James : When using the ipaddress library, all multicast addresses and networks return True when using the is_global method for their respective classes. I believe their are two possible fixes for this. 1) In practice no multicast addresses are globally routable. If our definition of is_global means the address is globally routable, then I propose adding not is_multicast to each class's is_global logic. 2) RFC 5771 (IPv4) and RFCs 4291 and 7346 (IPv6) both have guidelines for what MAY be routed on the public internet (as mentioned above multicast is not routed globally in practice). Logic following those guidelines should be added. IPv4: 224.0.1.0/24, AD-HOC I, II and III addresses 224.0.2.0 - 224.0.255.255, 224.3.0.0 - 224.4.255.255, and 233.252.0.0 - 233.255.255.255 IPv6: Multicast addresses with 0xE in the SCOPE field The current logic is inaccurate when looking at the relevant RFCs and worse when looking at how routing is actually implemented. Github PR submitted for option 1 above. I've also submitted a thread to NANOG's mailing list (currently pending moderator approval) posing a few questions regarding the RFCs above. I think it's unlikely that multicast will ever be publicly routed on the internet, so really we just need to define global here. My definition would be addresses that are routed on the public internet. ---------- components: Library (Lib) messages: 348942 nosy: bjames priority: normal severity: normal status: open title: ipaddress - is_global method all multicast addresses and networks return true _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 01:29:09 2019 From: report at bugs.python.org (Brandon James) Date: Sat, 03 Aug 2019 05:29:09 +0000 Subject: [issue37749] ipaddress - is_global method all multicast addresses and networks return true In-Reply-To: <1564809406.61.0.356559045946.issue37749@roundup.psfhosted.org> Message-ID: <1564810149.88.0.248027122266.issue37749@roundup.psfhosted.org> Change by Brandon James : ---------- keywords: +patch pull_requests: +14833 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15088 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 01:46:05 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 03 Aug 2019 05:46:05 +0000 Subject: [issue37444] Differing exception between builtins and importlib when importing beyond top-level package In-Reply-To: <1561749733.32.0.955430999512.issue37444@roundup.psfhosted.org> Message-ID: <1564811165.59.0.565530718808.issue37444@roundup.psfhosted.org> miss-islington added the comment: New changeset c5fa44944ee0a31a12b9a70776c7cb56c4dc39a2 by Miss Islington (bot) (Ngalim Siregar) in branch 'master': bpo-37444: Update differing exception between builtins and importlib (GH-14869) https://github.com/python/cpython/commit/c5fa44944ee0a31a12b9a70776c7cb56c4dc39a2 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 02:03:24 2019 From: report at bugs.python.org (hai shi) Date: Sat, 03 Aug 2019 06:03:24 +0000 Subject: [issue34697] ctypes: Crash if manually-created CField instance is used In-Reply-To: <1537031593.26.0.956365154283.issue34697@psf.upfronthosting.co.za> Message-ID: <1564812204.51.0.550052388549.issue34697@roundup.psfhosted.org> hai shi added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 02:12:31 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 03 Aug 2019 06:12:31 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564812751.18.0.235034665839.issue18049@roundup.psfhosted.org> Ronald Oussoren added the comment: New changeset 9670ce76b83bde950020f8d89c4d27168aaaf912 by Ronald Oussoren (Michael Felt) in branch 'master': bpo-18049: Define THREAD_STACK_SIZE for AIX to pass default recursion limit test (GH-15081) https://github.com/python/cpython/commit/9670ce76b83bde950020f8d89c4d27168aaaf912 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 03:18:56 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 03 Aug 2019 07:18:56 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564816736.42.0.339797716975.issue18049@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14834 pull_request: https://github.com/python/cpython/pull/15089 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 03:20:18 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Sat, 03 Aug 2019 07:20:18 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1564816818.39.0.587454627163.issue18049@roundup.psfhosted.org> Change by Ronald Oussoren : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 03:31:52 2019 From: report at bugs.python.org (hai shi) Date: Sat, 03 Aug 2019 07:31:52 +0000 Subject: [issue19692] Rename Py_SAFE_DOWNCAST In-Reply-To: <1385130295.49.0.846468108755.issue19692@psf.upfronthosting.co.za> Message-ID: <1564817512.51.0.979350508725.issue19692@roundup.psfhosted.org> Change by hai shi : ---------- keywords: +patch pull_requests: +14835 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15090 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 03:39:31 2019 From: report at bugs.python.org (hai shi) Date: Sat, 03 Aug 2019 07:39:31 +0000 Subject: [issue19692] Rename Py_SAFE_DOWNCAST In-Reply-To: <1385130295.49.0.846468108755.issue19692@psf.upfronthosting.co.za> Message-ID: <1564817971.22.0.0630940350555.issue19692@roundup.psfhosted.org> hai shi added the comment: Rename Py_SAFE_DOWNCAST in PR_15090. In the C API: Py_TRASHCAN_SAFE_BEGIN and Py_TRASHCAN_SAFE_END should be removed or keep it due to compatibility? In the stdlib: Looks that it's not changed is ok. ---------- nosy: +shihai1991 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 04:10:30 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 03 Aug 2019 08:10:30 +0000 Subject: [issue36502] str.isspace() for U+00A0 and U+202F differs from document In-Reply-To: <1554186967.56.0.21483381742.issue36502@roundup.psfhosted.org> Message-ID: <1564819830.62.0.100979668705.issue36502@roundup.psfhosted.org> Change by Greg Price : ---------- keywords: +patch pull_requests: +14836 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15019 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 04:18:56 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 03 Aug 2019 08:18:56 +0000 Subject: [issue36502] str.isspace() for U+00A0 and U+202F differs from document In-Reply-To: <1554186967.56.0.21483381742.issue36502@roundup.psfhosted.org> Message-ID: <1564820336.45.0.44310060774.issue36502@roundup.psfhosted.org> Greg Price added the comment: The actual behavior turns out to match that comment. See attached PR, which adds a test confirming that and also corrects the documentation. (A related issue is #18236 -- we should probably adjust the definition to match the one Unicode now provides. But meanwhile we'll want to correct the docs.) ---------- nosy: +Greg Price _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 04:54:37 2019 From: report at bugs.python.org (hai shi) Date: Sat, 03 Aug 2019 08:54:37 +0000 Subject: [issue37750] PyBuffer_FromContiguous not documented Message-ID: <1564822477.69.0.243179075111.issue37750@roundup.psfhosted.org> Change by hai shi : ---------- assignee: docs at python components: Documentation nosy: docs at python, shihai1991 priority: normal severity: normal status: open title: PyBuffer_FromContiguous not documented _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 04:56:58 2019 From: report at bugs.python.org (hai shi) Date: Sat, 03 Aug 2019 08:56:58 +0000 Subject: [issue37750] PyBuffer_FromContiguous not documented Message-ID: <1564822618.55.0.397769114373.issue37750@roundup.psfhosted.org> New submission from hai shi : as the title said. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 04:58:55 2019 From: report at bugs.python.org (hai shi) Date: Sat, 03 Aug 2019 08:58:55 +0000 Subject: [issue37750] PyBuffer_FromContiguous not documented In-Reply-To: <1564822618.55.0.397769114373.issue37750@roundup.psfhosted.org> Message-ID: <1564822735.38.0.895493542303.issue37750@roundup.psfhosted.org> Change by hai shi : ---------- keywords: +patch pull_requests: +14837 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15091 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 06:39:59 2019 From: report at bugs.python.org (Michael Felt) Date: Sat, 03 Aug 2019 10:39:59 +0000 Subject: [issue36273] test_thread leaks a core dump on PPC64 AIX 3.x In-Reply-To: <1552407244.81.0.665825370239.issue36273@roundup.psfhosted.org> Message-ID: <1564828799.64.0.503405433666.issue36273@roundup.psfhosted.org> Michael Felt added the comment: resolved via issue18049 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 06:43:27 2019 From: report at bugs.python.org (Michael Felt) Date: Sat, 03 Aug 2019 10:43:27 +0000 Subject: [issue36273] test_thread leaks a core dump on PPC64 AIX 3.x In-Reply-To: <1552407244.81.0.665825370239.issue36273@roundup.psfhosted.org> Message-ID: <1564829007.13.0.897930304399.issue36273@roundup.psfhosted.org> Michael Felt added the comment: correction - issue18049 was related to test_threading. cannot say for sure that "this" is resolved by 18049. apologies for noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 06:55:35 2019 From: report at bugs.python.org (Stefan Krah) Date: Sat, 03 Aug 2019 10:55:35 +0000 Subject: [issue19692] Rename Py_SAFE_DOWNCAST In-Reply-To: <1385130295.49.0.846468108755.issue19692@psf.upfronthosting.co.za> Message-ID: <1564829735.07.0.569912495627.issue19692@roundup.psfhosted.org> Stefan Krah added the comment: Why would one not abort() in release mode? If the cast is inexact, the results will usually be so wrong that even on a web server a hard exit is preferable. I don't think the check costs much time with branch prediction. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 07:10:28 2019 From: report at bugs.python.org (STINNER Victor) Date: Sat, 03 Aug 2019 11:10:28 +0000 Subject: [issue19692] Rename Py_SAFE_DOWNCAST In-Reply-To: <1385130295.49.0.846468108755.issue19692@psf.upfronthosting.co.za> Message-ID: <1564830628.65.0.157254978358.issue19692@roundup.psfhosted.org> STINNER Victor added the comment: I dislike this macro. A cast is either safe or unsafe. If it is safe, (type)var would be better. If it is unsafe, well, it would be better to add a runtime check. No? (I mean better error reporting than abort() pnly in debug mode.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 07:34:13 2019 From: report at bugs.python.org (Jordon.X) Date: Sat, 03 Aug 2019 11:34:13 +0000 Subject: [issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores. Message-ID: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org> New submission from Jordon.X <9651234 at qq.com>: In codecs.c, when _PyCodec_Lookup() call normalizestring(), both spaces and hyphens should be convered to underscores. Not convert spaces to hyphens. see:https://github.com/python/peps/blob/master/pep-0100.txt, Codecs (Coder/Decoders) Lookup ---------- components: Unicode messages: 348953 nosy: ezio.melotti, qigangxu, vstinner priority: normal severity: normal status: open title: In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores. type: behavior versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 07:55:54 2019 From: report at bugs.python.org (Jordon.X) Date: Sat, 03 Aug 2019 11:55:54 +0000 Subject: [issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores. In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org> Message-ID: <1564833354.64.0.460470529684.issue37751@roundup.psfhosted.org> Jordon.X <9651234 at qq.com> added the comment: and I will try to fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 08:10:17 2019 From: report at bugs.python.org (Jordon.X) Date: Sat, 03 Aug 2019 12:10:17 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in normalizestring(codecs.c) Message-ID: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> New submission from Jordon.X <9651234 at qq.com>: In normalizestring(), ch = Py_TOLOWER(Py_CHARMASK(ch)); Where Py_TOLOWER is defined as following, #define Py_TOLOWER(c) (_Py_ctype_tolower[Py_CHARMASK(c)]) Redundant Py_CHARMASK called here. ---------- components: Unicode messages: 348955 nosy: ezio.melotti, qigangxu, vstinner priority: normal severity: normal status: open title: Redundant Py_CHARMASK called in normalizestring(codecs.c) type: performance versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 08:45:33 2019 From: report at bugs.python.org (Jordon.X) Date: Sat, 03 Aug 2019 12:45:33 +0000 Subject: [issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores. In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org> Message-ID: <1564836333.89.0.599937076432.issue37751@roundup.psfhosted.org> Change by Jordon.X <9651234 at qq.com>: ---------- keywords: +patch pull_requests: +14838 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15092 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 08:57:14 2019 From: report at bugs.python.org (hai shi) Date: Sat, 03 Aug 2019 12:57:14 +0000 Subject: [issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores. In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org> Message-ID: <1564837034.53.0.876198783401.issue37751@roundup.psfhosted.org> hai shi added the comment: Hm, there is a bit misleading between desc(https://github.com/python/cpython/blob/master/Python/codecs.c#L53) and the code (https://github.com/python/cpython/blob/master/Python/codecs.c#L74). ---------- nosy: +shihai1991 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 08:58:48 2019 From: report at bugs.python.org (hai shi) Date: Sat, 03 Aug 2019 12:58:48 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in normalizestring(codecs.c) In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1564837128.17.0.472262995767.issue37752@roundup.psfhosted.org> hai shi added the comment: Good catch ;), try to fix it, thanks. ---------- nosy: +shihai1991 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 09:12:00 2019 From: report at bugs.python.org (Tal Einat) Date: Sat, 03 Aug 2019 13:12:00 +0000 Subject: [issue37748] IDLE: Re-order run menu In-Reply-To: <1564807705.24.0.436490903651.issue37748@roundup.psfhosted.org> Message-ID: <1564837920.15.0.221571965931.issue37748@roundup.psfhosted.org> Tal Einat added the comment: Perhaps we should use a separator to differentiate between things that run in the shell and those that don't, e.g. as following: Run Module Run... Customized Python Shell ------------- Check Module ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 09:13:33 2019 From: report at bugs.python.org (Jordon.X) Date: Sat, 03 Aug 2019 13:13:33 +0000 Subject: [issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores. In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org> Message-ID: <1564838013.57.0.0983087568982.issue37751@roundup.psfhosted.org> Jordon.X <9651234 at qq.com> added the comment: The design and code of the following four places need to be consistent, No.1 https://github.com/python/peps/blob/master/pep-0100.txt#L292 No.2 https://github.com/python/cpython/blob/master/Python/codecs.c#L113 No.3 https://github.com/python/cpython/blob/master/Python/codecs.c#L53 No.4 https://github.com/python/cpython/blob/master/Python/codecs.c#74 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 09:49:25 2019 From: report at bugs.python.org (Jordon.X) Date: Sat, 03 Aug 2019 13:49:25 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in normalizestring(codecs.c) In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1564840165.12.0.681549270761.issue37752@roundup.psfhosted.org> Change by Jordon.X <9651234 at qq.com>: ---------- keywords: +patch, patch pull_requests: +14839, 14840 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15093 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 09:49:25 2019 From: report at bugs.python.org (Jordon.X) Date: Sat, 03 Aug 2019 13:49:25 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in normalizestring(codecs.c) In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1564840165.07.0.76844338292.issue37752@roundup.psfhosted.org> Change by Jordon.X <9651234 at qq.com>: ---------- keywords: +patch pull_requests: +14839 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15093 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 09:58:20 2019 From: report at bugs.python.org (Sascha Silbe) Date: Sat, 03 Aug 2019 13:58:20 +0000 Subject: [issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses In-Reply-To: <1545303410.27.0.788709270274.issue35545@psf.upfronthosting.co.za> Message-ID: <1564840700.24.0.639342025844.issue35545@roundup.psfhosted.org> Change by Sascha Silbe : ---------- nosy: +sascha_silbe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 10:00:14 2019 From: report at bugs.python.org (hai shi) Date: Sat, 03 Aug 2019 14:00:14 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in normalizestring(codecs.c) In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1564840814.27.0.433273229131.issue37752@roundup.psfhosted.org> hai shi added the comment: Looks the PR is confused. Make sure: one PR on one dev branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 10:23:18 2019 From: report at bugs.python.org (Xinmeng Xia) Date: Sat, 03 Aug 2019 14:23:18 +0000 Subject: [issue37753] 2to3 not handing "<=" Message-ID: <1564842198.64.0.915142421848.issue37753@roundup.psfhosted.org> New submission from Xinmeng Xia : After conversion of 2to3 , run simple-example.py and the following error will happen. Traceback (most recent call last): File "/home/xxm/Desktop/instrument/datasetpy3/nflgame/simple_example.py", line 15, in plays = nflgame.combine_plays(games) File "/home/xxm/Desktop/instrument/datasetpy3/nflgame/nflgame/__init__.py", line 396, in combine_plays chain = itertools.chain(*[g.drives.plays() for g in games]) File "/home/xxm/Desktop/instrument/datasetpy3/nflgame/nflgame/__init__.py", line 396, in chain = itertools.chain(*[g.drives.plays() for g in games]) File "/home/xxm/Desktop/instrument/datasetpy3/nflgame/nflgame/game.py", line 407, in __getattr__ self.__drives = _json_drives(self, self.home, self.data['drives']) File "/home/xxm/Desktop/instrument/datasetpy3/nflgame/nflgame/game.py", line 675, in _json_drives d = Drive(game, i, home_team, data[str(drive_num)]) File "/home/xxm/Desktop/instrument/datasetpy3/nflgame/nflgame/game.py", line 516, in __init__ if self.time_end <= self.time_start \ TypeError: '<=' not supported between instances of 'GameClock' and 'GameClock' ---------- components: 2to3 (2.x to 3.x conversion tool) files: simple_example.py messages: 348961 nosy: xxm priority: normal severity: normal status: open title: 2to3 not handing "<=" type: compile error versions: Python 3.7 Added file: https://bugs.python.org/file48528/simple_example.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 10:24:34 2019 From: report at bugs.python.org (Anthony Sottile) Date: Sat, 03 Aug 2019 14:24:34 +0000 Subject: [issue37433] syntax error in multiline f-string produces ~40k spaces output In-Reply-To: <1561659761.86.0.416757939602.issue37433@roundup.psfhosted.org> Message-ID: <1564842274.13.0.0663072507253.issue37433@roundup.psfhosted.org> Anthony Sottile added the comment: seems unrelated and does the same on older versions of python: ``` $ python3.5 t.py File "t.py", line 4 ^ SyntaxError: EOF while scanning triple-quoted string literal ``` I'd suggest a new issue or finding the dupe ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 10:37:34 2019 From: report at bugs.python.org (Rhodri James) Date: Sat, 03 Aug 2019 14:37:34 +0000 Subject: [issue1047397] cgitb failures Message-ID: <1564843054.38.0.552040218863.issue1047397@roundup.psfhosted.org> Change by Rhodri James : ---------- pull_requests: +14841 pull_request: https://github.com/python/cpython/pull/15094 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 10:39:49 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 03 Aug 2019 14:39:49 +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: <1564843189.8.0.310432898836.issue20523@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 Aug 3 10:53:33 2019 From: report at bugs.python.org (Rhodri James) Date: Sat, 03 Aug 2019 14:53:33 +0000 Subject: [issue10879] cgi memory usage In-Reply-To: <1294648490.09.0.987257947586.issue10879@psf.upfronthosting.co.za> Message-ID: <1564844013.27.0.307193085706.issue10879@roundup.psfhosted.org> Change by Rhodri James : ---------- nosy: +Rhodri James, ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 10:56:02 2019 From: report at bugs.python.org (Rhodri James) Date: Sat, 03 Aug 2019 14:56:02 +0000 Subject: [issue9968] Let cgi.FieldStorage have named uploaded file In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za> Message-ID: <1564844162.7.0.597217786045.issue9968@roundup.psfhosted.org> Change by Rhodri James : ---------- nosy: +Rhodri James, ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 10:57:01 2019 From: report at bugs.python.org (Jordon.X) Date: Sat, 03 Aug 2019 14:57:01 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in normalizestring(codecs.c) In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1564844221.69.0.983458798491.issue37752@roundup.psfhosted.org> Change by Jordon.X <9651234 at qq.com>: ---------- pull_requests: +14842 pull_request: https://github.com/python/cpython/pull/15095 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 10:59:28 2019 From: report at bugs.python.org (Rhodri James) Date: Sat, 03 Aug 2019 14:59:28 +0000 Subject: [issue21705] cgi.py: Multipart with more than one file is misparsed In-Reply-To: <1402401424.17.0.414317354507.issue21705@psf.upfronthosting.co.za> Message-ID: <1564844368.94.0.549974921292.issue21705@roundup.psfhosted.org> Change by Rhodri James : ---------- nosy: +Rhodri James, ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 11:12:36 2019 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 03 Aug 2019 15:12:36 +0000 Subject: [issue37753] 2to3 not handing "<=" In-Reply-To: <1564842198.64.0.915142421848.issue37753@roundup.psfhosted.org> Message-ID: <1564845156.03.0.81364693024.issue37753@roundup.psfhosted.org> Eric V. Smith added the comment: 2to3 is not designed to turn every valid python2 program into a valid python3 program. You'll have to provide a way to compare GameClock objects. I suggest you look at http://python3porting.com. You should read the whole site, it's a great resource. Specifically in this case, see http://python3porting.com/problems.html#unorderable-types-cmp-and-cmp ---------- nosy: +eric.smith resolution: -> not a bug stage: -> resolved status: open -> closed type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 11:19:59 2019 From: report at bugs.python.org (Giovanni Cappellotto) Date: Sat, 03 Aug 2019 15:19:59 +0000 Subject: [issue15266] Perform the same checks as PyPI for Description field In-Reply-To: <1341614489.26.0.385769914645.issue15266@psf.upfronthosting.co.za> Message-ID: <1564845599.66.0.152741264272.issue15266@roundup.psfhosted.org> Giovanni Cappellotto added the comment: Hi Victor, This is the 3rd issue in a row I found in the "Easy issues" list where you added a comment saying > I remove the "Easy" label Why are can I still find these issues in the "Easy issues" list? Do you mean that you already removed the "Easy" label or that you plan to remove it? ---------- nosy: +potomak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 12:04:11 2019 From: report at bugs.python.org (hai shi) Date: Sat, 03 Aug 2019 16:04:11 +0000 Subject: =?utf-8?q?=5Bissue37681=5D_warning=3A_=E2=80=98no=5Fsanitize=5Fthread?= =?utf-8?b?4oCZ?= In-Reply-To: <1564070558.89.0.656147417061.issue37681@roundup.psfhosted.org> Message-ID: <1564848251.15.0.164156494457.issue37681@roundup.psfhosted.org> hai shi added the comment: I checked no_sanitize_thread in some gcc manual of different version. And looks the no_sanitize_thread from gcc 5.1.0 [3](not 4.8) [1] https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/Function-Attributes.html#Function-Attributes [2] https://gcc.gnu.org/onlinedocs/gcc-4.9.4/gcc/Function-Attributes.html#Function-Attributes [3] https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Function-Attributes.html#Function-Attributes [4] https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/Function-Attributes.html#Function-Attributes Alexey have some descr of TSAN in https://bugs.python.org/issue35204(Looks `GCC introduced TSan together with ASan in 4.8` is wrong) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 12:09:09 2019 From: report at bugs.python.org (hai shi) Date: Sat, 03 Aug 2019 16:09:09 +0000 Subject: =?utf-8?q?=5Bissue37681=5D_warning=3A_=E2=80=98no=5Fsanitize=5Fthread?= =?utf-8?b?4oCZ?= In-Reply-To: <1564070558.89.0.656147417061.issue37681@roundup.psfhosted.org> Message-ID: <1564848549.49.0.80772004697.issue37681@roundup.psfhosted.org> Change by hai shi : ---------- keywords: +patch pull_requests: +14843 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15096 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 13:45:36 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 03 Aug 2019 17:45:36 +0000 Subject: [issue37748] IDLE: Re-order run menu In-Reply-To: <1564807705.24.0.436490903651.issue37748@roundup.psfhosted.org> Message-ID: <1564854336.23.0.0193506514255.issue37748@roundup.psfhosted.org> Terry J. Reedy added the comment: Run Module and Run Customized both run Check Module first. All three involve the code in the particular editor. Restarting Shell is not editor specific, so I see *it* as the oddball. The proposed Run Checker #21880, would involve the editor code, might or might not Check Module first, but would not run in or involve Shell at all. It might be a good candidate for the last position. If it were added, I think my first option, Run Module ... Python Shell would be better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 16:07:24 2019 From: report at bugs.python.org (Tal Einat) Date: Sat, 03 Aug 2019 20:07:24 +0000 Subject: [issue37748] IDLE: Re-order run menu In-Reply-To: <1564807705.24.0.436490903651.issue37748@roundup.psfhosted.org> Message-ID: <1564862844.41.0.915446648272.issue37748@roundup.psfhosted.org> Tal Einat added the comment: Ah, my bad, I mixed up "Check Module" with the proposed external checkers feature. Anyways, I'm +1 on this reordering, but have no opinion on the specifics. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 16:44:33 2019 From: report at bugs.python.org (Ned Deily) Date: Sat, 03 Aug 2019 20:44:33 +0000 Subject: [issue37706] IDLE test_sidebar test_(click/drag)_selection fail on macOS 8.6 In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1564865073.76.0.601916899678.issue37706@roundup.psfhosted.org> Ned Deily added the comment: I can reproduce this at will on all of the real and virtual macOS systems I've tried (10.12 through 10.14) even building with ActiveTcl 8.5.18. Tal, make sure the appropriate tests cases are actually running. If you don't have a proper Gui installation of your Python, many of the GUI-related test cases in test_idle are silently skipped unless you add -v or something: /usr/local/bin/python3.8 -m test -v -uall test_idle ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 19:57:03 2019 From: report at bugs.python.org (Jordon.X) Date: Sat, 03 Aug 2019 23:57:03 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in normalizestring(codecs.c) In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1564876623.47.0.435430165505.issue37752@roundup.psfhosted.org> Jordon.X <9651234 at qq.com> added the comment: Thanks Hai, for your careful check. There is a misoperation in PR 15093. Now I closed PR 15093. And resubmit code as PR 15095. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 20:57:37 2019 From: report at bugs.python.org (Ma Lin) Date: Sun, 04 Aug 2019 00:57:37 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in normalizestring(codecs.c) In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1564880257.23.0.321857508719.issue37752@roundup.psfhosted.org> Ma Lin added the comment: Search "Py_CHARMASK" in Python source code, there are more than a dozen Py_CHARMASK can be deleted: https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Python/mystrtoul.c#L102 https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Python/dynload_aix.c#L143 https://github.com/python/cpython/blob/530f506ac91338b55cf2be71b1cdf50cb077512f/Modules/unicodedata.c#L963 ... ---------- nosy: +Ma Lin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 21:18:51 2019 From: report at bugs.python.org (Ma Lin) Date: Sun, 04 Aug 2019 01:18:51 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in normalizestring(codecs.c) In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1564881531.49.0.925024285869.issue37752@roundup.psfhosted.org> Ma Lin added the comment: Or remove Py_CHARMASK in Py_ISxxx/Py_TOLOWER/Py_TOUPPER macros? Sometimes `c` is already a unsinged char, Py_CHARMASK is not necessary in these cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 22:50:43 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Aug 2019 02:50:43 +0000 Subject: [issue37748] IDLE: Re-order run menu In-Reply-To: <1564807705.24.0.436490903651.issue37748@roundup.psfhosted.org> Message-ID: <1564887043.43.0.115891748931.issue37748@roundup.psfhosted.org> Raymond Hettinger added the comment: +1 for the proposed reverse ordering: Run Module Run... Customized Check Module Python Shell ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 3 23:13:49 2019 From: report at bugs.python.org (Jordon.X) Date: Sun, 04 Aug 2019 03:13:49 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in normalizestring(codecs.c) In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1564888429.33.0.981056296812.issue37752@roundup.psfhosted.org> Jordon.X <9651234 at qq.com> added the comment: Thanks Ma,I also think all these redundant Py_CHARMASK should be deleted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 02:37:56 2019 From: report at bugs.python.org (Vinay Sharma) Date: Sun, 04 Aug 2019 06:37:56 +0000 Subject: [issue37185] use os.memfd_create in multiprocessing.shared_memory? In-Reply-To: <1559859610.5.0.492744373458.issue37185@roundup.psfhosted.org> Message-ID: <1564900676.96.0.442472435763.issue37185@roundup.psfhosted.org> Vinay Sharma added the comment: Hi @pierreglaser, I recently started using the shared_memory module in multiprocessing , and as you said using memfd_create wouldn't require resource tracking is true. But, I was wondering if these memory segments can't be related/mapped using a unique name, then how will other unrelated processes to which this file descriptor cannot be passed, use this shared memory segment. Also, would releasing when all the references to the segment are dropped an expected behaviour. Let's suppose a process creates a shared memory segment and exits. After 5 seconds another process is started, which tries to access the same memory segment. But it won't be able to since all references would have been dropped by the first process, thereby releasing this memory segment. Feel free to comment, if I misinterpreted anything. ---------- nosy: +vinay0410 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 03:41:20 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 04 Aug 2019 07:41:20 +0000 Subject: [issue37723] important performance regression on regular expression parsing In-Reply-To: <1564524154.39.0.245394903935.issue37723@roundup.psfhosted.org> Message-ID: <1564904480.32.0.138354398955.issue37723@roundup.psfhosted.org> Serhiy Storchaka added the comment: Thank you for your contribution yannvgn. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 04:55:44 2019 From: report at bugs.python.org (Zackery Spytz) Date: Sun, 04 Aug 2019 08:55:44 +0000 Subject: [issue35771] IDLE: Fix tooltip Hovertiptest failure In-Reply-To: <1547794267.4.0.582455332849.issue35771@roundup.psfhosted.org> Message-ID: <1564908944.48.0.309492480038.issue35771@roundup.psfhosted.org> Zackery Spytz added the comment: Sorry for the delay. I'm using Lubuntu 19.04. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 05:38:49 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 04 Aug 2019 09:38:49 +0000 Subject: [issue37685] Fix equality checks for some types In-Reply-To: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org> Message-ID: <1564911529.87.0.118261142251.issue37685@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 17e52649c0e7e9389f1cc2444a53f059e24e6bca by Serhiy Storchaka in branch 'master': bpo-37685: Fixed comparisons of datetime.timedelta and datetime.timezone. (GH-14996) https://github.com/python/cpython/commit/17e52649c0e7e9389f1cc2444a53f059e24e6bca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 05:39:04 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 09:39:04 +0000 Subject: [issue37685] Fix equality checks for some types In-Reply-To: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org> Message-ID: <1564911544.08.0.779345767131.issue37685@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14844 pull_request: https://github.com/python/cpython/pull/15102 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 06:02:00 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 10:02:00 +0000 Subject: [issue37685] Fix equality checks for some types In-Reply-To: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org> Message-ID: <1564912920.42.0.689864020356.issue37685@roundup.psfhosted.org> miss-islington added the comment: New changeset dde944f9df8dea28c07935ebd6de06db7e575c12 by Miss Islington (bot) in branch '3.8': bpo-37685: Fixed comparisons of datetime.timedelta and datetime.timezone. (GH-14996) https://github.com/python/cpython/commit/dde944f9df8dea28c07935ebd6de06db7e575c12 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 06:19:32 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 04 Aug 2019 10:19:32 +0000 Subject: [issue37706] IDLE test_sidebar test_(click/drag)_selection fail on macOS 8.6 In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1564913972.81.0.0241535835493.issue37706@roundup.psfhosted.org> Change by Tal Einat : ---------- pull_requests: +14845 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15103 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 06:25:59 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 04 Aug 2019 10:25:59 +0000 Subject: [issue37706] IDLE test_sidebar test_(click/drag)_selection fail on macOS 8.6 In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1564914359.93.0.481182102843.issue37706@roundup.psfhosted.org> Tal Einat added the comment: I was even able to reproduce this on Windows, though not on my Mac. A sneaky bug. See PR GH-15103 with a fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 06:32:38 2019 From: report at bugs.python.org (Vinay Sharma) Date: Sun, 04 Aug 2019 10:32:38 +0000 Subject: [issue37754] alter size of segment using multiprocessing.shared_memory Message-ID: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> New submission from Vinay Sharma : Hi, I am opening this to discuss about some possible enhancements in the multiprocessing.shared_memory module. I have recently started using multiprocessing.shared_memory and realised that currently the module provides no functionality to alter the size of the shared memory segment, plus the process has to know beforehand whether to create a segment or open an existing one, unlike shm_open in C, where segment can be automatically created if it doesn't exist. For an end user perspective I believe that these functionalities would be really helpful, and I would be happy to contribute, if you believe that they are necessary. I would also like to mention that I agree this might be by design, or because of some challenges, in which case it would be very helpful if I can know them. ---------- components: Library (Lib) messages: 348980 nosy: davin, pitrou, vinay0410 priority: normal severity: normal status: open title: alter size of segment using multiprocessing.shared_memory type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 06:49:09 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Sun, 04 Aug 2019 10:49:09 +0000 Subject: [issue33997] multiprocessing Pool hangs in terminate() In-Reply-To: <1530275873.32.0.56676864532.issue33997@psf.upfronthosting.co.za> Message-ID: <1564915749.69.0.483445473441.issue33997@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- nosy: +remi.lapeyre _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 07:00:06 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 04 Aug 2019 11:00:06 +0000 Subject: [issue37685] Fix equality checks for some types In-Reply-To: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org> Message-ID: <1564916406.51.0.459847552857.issue37685@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +14846 pull_request: https://github.com/python/cpython/pull/15104 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 07:12:51 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 04 Aug 2019 11:12:51 +0000 Subject: [issue37648] Fix minor inconsistency in the order of == operands In-Reply-To: <1563782337.34.0.926786223428.issue37648@roundup.psfhosted.org> Message-ID: <1564917171.33.0.1858126294.issue37648@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 18b711c5a7f90d88fb74748f18fa8ef49d8486c7 by Serhiy Storchaka in branch 'master': bpo-37648: Fixed minor inconsistency in some __contains__. (GH-14904) https://github.com/python/cpython/commit/18b711c5a7f90d88fb74748f18fa8ef49d8486c7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 07:14:56 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 04 Aug 2019 11:14:56 +0000 Subject: [issue37648] Fix minor inconsistency in the order of == operands In-Reply-To: <1563782337.34.0.926786223428.issue37648@roundup.psfhosted.org> Message-ID: <1564917296.82.0.370296230629.issue37648@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 08:28:25 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 04 Aug 2019 12:28:25 +0000 Subject: [issue37685] Fix equality checks for some types In-Reply-To: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org> Message-ID: <1564921705.27.0.92800063836.issue37685@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 6ed20e54e4c110e9adcfb70aba85310625e3edb4 by Serhiy Storchaka in branch '3.7': [3.7] bpo-37685: Fixed comparisons of datetime.timedelta and datetime.timezone. (GH-14996) (GH-15104) https://github.com/python/cpython/commit/6ed20e54e4c110e9adcfb70aba85310625e3edb4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 08:48:20 2019 From: report at bugs.python.org (=?utf-8?q?Enrico_Tr=C3=B6ger?=) Date: Sun, 04 Aug 2019 12:48:20 +0000 Subject: [issue37755] pydoc topics, keywords and symbols always use pager instead of output Message-ID: <1564922900.31.0.640915952302.issue37755@roundup.psfhosted.org> New submission from Enrico Tr?ger : I noticed a probably unintended behavior in help() usage: when an output is set on pydoc.Helper(), most of its methods use this output instead of a pager. But 'True', 'False' and 'None' as well as all topics, keywords and symbols always use a pager instead of the configured output. My use case is to use the pydoc help system to display help contents in Geany (a text editor) in a graphical manner (and so I cannot make any use of a pager). Example code: #!/usr/bin/env python3 # -*- coding: utf-8 -*- from io import StringIO import pydoc import sys if __name__ == '__main__': help_text = StringIO() helper = pydoc.Helper(output=help_text) # help contents are written to help_text as expected helper.help('pydoc') # the following calls each show the help contents in a pager instead # of using the configured output helper.help('True') helper.help('False') helper.help('None') helper.help('**') # symbol example helper.help('SEQUENCES') # topic example helper.help('await') # keyword example Tested against Python 3.7.3. ---------- components: Library (Lib) messages: 348983 nosy: eht16 priority: normal severity: normal status: open title: pydoc topics, keywords and symbols always use pager instead of output type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 08:55:23 2019 From: report at bugs.python.org (=?utf-8?q?Enrico_Tr=C3=B6ger?=) Date: Sun, 04 Aug 2019 12:55:23 +0000 Subject: [issue37755] pydoc topics, keywords and symbols always use pager instead of output In-Reply-To: <1564922900.31.0.640915952302.issue37755@roundup.psfhosted.org> Message-ID: <1564923323.71.0.864284047565.issue37755@roundup.psfhosted.org> Change by Enrico Tr?ger : ---------- keywords: +patch pull_requests: +14847 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15105 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 09:43:39 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 13:43:39 +0000 Subject: [issue37730] NotImplemented is used instead of NotImplementedError in docs In-Reply-To: <1564576160.73.0.181501805035.issue37730@roundup.psfhosted.org> Message-ID: <1564926219.26.0.366234579868.issue37730@roundup.psfhosted.org> miss-islington added the comment: New changeset dd5f8abb54923bf2efea51b7a553ca1fca9cad68 by Miss Islington (bot) in branch '3.8': bpo-37730: Fix usage of NotImplemented instead of NotImplementedError in docs. (GH-15062) https://github.com/python/cpython/commit/dd5f8abb54923bf2efea51b7a553ca1fca9cad68 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 09:48:09 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 04 Aug 2019 13:48:09 +0000 Subject: [issue37730] NotImplemented is used instead of NotImplementedError in docs In-Reply-To: <1564576160.73.0.181501805035.issue37730@roundup.psfhosted.org> Message-ID: <1564926489.44.0.629485743585.issue37730@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +14848 pull_request: https://github.com/python/cpython/pull/15106 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 10:06:58 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 04 Aug 2019 14:06:58 +0000 Subject: [issue37730] NotImplemented is used instead of NotImplementedError in docs In-Reply-To: <1564576160.73.0.181501805035.issue37730@roundup.psfhosted.org> Message-ID: <1564927618.41.0.41821761417.issue37730@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 8cd630578451a062dcf46fbb21274520ae36c399 by Serhiy Storchaka in branch '3.7': [3.7] bpo-37730: Fix usage of NotImplemented instead of NotImplementedError in docs. (GH-15062). (GH-15106) https://github.com/python/cpython/commit/8cd630578451a062dcf46fbb21274520ae36c399 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 10:48:44 2019 From: report at bugs.python.org (Giovanni Cappellotto) Date: Sun, 04 Aug 2019 14:48:44 +0000 Subject: [issue37700] shutil.copyfile does not raise SpecialFileError for socket files In-Reply-To: <1564374136.89.0.594392746042.issue37700@roundup.psfhosted.org> Message-ID: <1564930124.8.0.355394304292.issue37700@roundup.psfhosted.org> Change by Giovanni Cappellotto : ---------- nosy: +potomak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 10:58:27 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 Aug 2019 14:58:27 +0000 Subject: [issue37706] IDLE test_sidebar test_(click/drag)_selection fail on macOS 8.6 In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1564930707.13.0.427453076414.issue37706@roundup.psfhosted.org> Ned Deily added the comment: With PR 15103. the tests appear to no longer fail on macOS. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 11:09:10 2019 From: report at bugs.python.org (Ned Deily) Date: Sun, 04 Aug 2019 15:09:10 +0000 Subject: [issue37706] IDLE test_sidebar test_(click/drag)_selection fail on macOS 8.6 In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1564931350.89.0.324126707231.issue37706@roundup.psfhosted.org> Ned Deily added the comment: Terry, with regard to Azure testing and elsewhere: presumably most of the CI runs are run from processes without a GUI-capable "console" so that test failures like this one would never be seen as test cases requiring a GUI interface would be silently skipped by test_idle (likewise for some tk tests). Perhaps the tests should issue a message when a GUI isn't present even when -v isn't selected? Or perhaps a message in test.pythoninfo? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 11:22:58 2019 From: report at bugs.python.org (bfbfbfb bfbfbf) Date: Sun, 04 Aug 2019 15:22:58 +0000 Subject: [issue37756] Error 0x80070643 when installing Message-ID: <1564932178.65.0.171539834023.issue37756@roundup.psfhosted.org> New submission from bfbfbfb bfbfbf : When installing python 3.7.4 64bit an error occurs 0x80070643, win10 ---------- components: Installation files: Python 3.7.4 (32-bit)_20190804181255.log messages: 348988 nosy: bfbfbfb bfbfbf priority: normal severity: normal status: open title: Error 0x80070643 when installing type: crash versions: Python 3.7 Added file: https://bugs.python.org/file48529/Python 3.7.4 (32-bit)_20190804181255.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 11:30:25 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 04 Aug 2019 15:30:25 +0000 Subject: [issue37756] Error 0x80070643 when installing In-Reply-To: <1564932178.65.0.171539834023.issue37756@roundup.psfhosted.org> Message-ID: <1564932625.23.0.179483545444.issue37756@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 Sun Aug 4 12:25:34 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 04 Aug 2019 16:25:34 +0000 Subject: [issue37706] IDLE test_sidebar test_(click/drag)_selection fail on macOS 8.6 In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1564935934.33.0.0781284458428.issue37706@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset 86f1a18abfee5939452f468d80de998918e2afd2 by Terry Jan Reedy (Tal Einat) in branch 'master': bpo-37706: IDLE - fix sidebar code bug and drag tests (GH-15103) https://github.com/python/cpython/commit/86f1a18abfee5939452f468d80de998918e2afd2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 12:25:39 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 16:25:39 +0000 Subject: [issue37706] IDLE test_sidebar test_(click/drag)_selection fail on macOS 8.6 In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1564935939.84.0.182075929069.issue37706@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14849 pull_request: https://github.com/python/cpython/pull/15107 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 12:25:45 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 16:25:45 +0000 Subject: [issue37706] IDLE test_sidebar test_(click/drag)_selection fail on macOS 8.6 In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1564935945.46.0.855852135139.issue37706@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14850 pull_request: https://github.com/python/cpython/pull/15108 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 12:43:59 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 16:43:59 +0000 Subject: [issue37706] IDLE test_sidebar test_(click/drag)_selection fail on macOS 8.6 In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1564937039.41.0.244748821017.issue37706@roundup.psfhosted.org> miss-islington added the comment: New changeset 1d2b4dba6ccbeb90ef797034b775c0f1ed17d1a0 by Miss Islington (bot) in branch '3.8': bpo-37706: IDLE - fix sidebar code bug and drag tests (GH-15103) https://github.com/python/cpython/commit/1d2b4dba6ccbeb90ef797034b775c0f1ed17d1a0 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 12:47:14 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 16:47:14 +0000 Subject: [issue37706] IDLE test_sidebar test_(click/drag)_selection fail on macOS 8.6 In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1564937234.67.0.309624155723.issue37706@roundup.psfhosted.org> miss-islington added the comment: New changeset 9e0c48a002c144d910a46a74b76b02179502b9aa by Miss Islington (bot) in branch '3.7': bpo-37706: IDLE - fix sidebar code bug and drag tests (GH-15103) https://github.com/python/cpython/commit/9e0c48a002c144d910a46a74b76b02179502b9aa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 12:56:03 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 04 Aug 2019 16:56:03 +0000 Subject: [issue37706] IDLE: fix sidebar click-drag bug and macOS test failures In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1564937763.73.0.307836037475.issue37706@roundup.psfhosted.org> Terry J. Reedy added the comment: Tal, thanks for the fix. Ned, thanks for the quick confirmation. Closing. Ned, I don't understand you last comment. The only CI testing on macOS is done by Azure. My understanding is that Azure runs a virtual console on Mac as well as linux, so it can run GUI (tk) tests. But it is using the 'wrong' tcl/tk on Mac. Steve, can you comment? ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed title: IDLE test_sidebar test_(click/drag)_selection fail on macOS 8.6 -> IDLE: fix sidebar click-drag bug and macOS test failures _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 13:11:37 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 04 Aug 2019 17:11:37 +0000 Subject: [issue37449] Move ensurepip off of pkgutil and to importlib.resources In-Reply-To: <1561860772.49.0.185483718697.issue37449@roundup.psfhosted.org> Message-ID: <1564938697.49.0.38320468969.issue37449@roundup.psfhosted.org> Joannah Nanjekye added the comment: To be exact, the change should use importlib.resources.read_binary which reads bytes like pkgutil.get_data(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 13:20:11 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 04 Aug 2019 17:20:11 +0000 Subject: [issue37449] Move ensurepip off of pkgutil and to importlib.resources In-Reply-To: <1561860772.49.0.185483718697.issue37449@roundup.psfhosted.org> Message-ID: <1564939211.51.0.616337019684.issue37449@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- keywords: +patch pull_requests: +14851 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15109 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 14:16:37 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Aug 2019 18:16:37 +0000 Subject: [issue36324] Inverse cumulative normal distribution function In-Reply-To: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org> Message-ID: <1564942597.86.0.268073793088.issue36324@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +14852 pull_request: https://github.com/python/cpython/pull/15110 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 14:19:40 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 04 Aug 2019 18:19:40 +0000 Subject: [issue15266] Perform the same checks as PyPI for Description field In-Reply-To: <1341614489.26.0.385769914645.issue15266@psf.upfronthosting.co.za> Message-ID: <1564942780.43.0.614050825199.issue15266@roundup.psfhosted.org> Joannah Nanjekye added the comment: @Giovanni , If you look closely, the issue still has the easy issue label that is why you still see it in the "Easy issues" list. Which means he has not removed the label yet. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 14:27:23 2019 From: report at bugs.python.org (Zackery Spytz) Date: Sun, 04 Aug 2019 18:27:23 +0000 Subject: [issue36279] os.wait3() leaks some uninitialized stack when no processes exist In-Reply-To: <1552447660.04.0.72531550499.issue36279@roundup.psfhosted.org> Message-ID: <1564943243.07.0.684712037166.issue36279@roundup.psfhosted.org> Change by Zackery Spytz : ---------- pull_requests: +14853 pull_request: https://github.com/python/cpython/pull/15111 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 14:52:08 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Aug 2019 18:52:08 +0000 Subject: [issue36324] Inverse cumulative normal distribution function In-Reply-To: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org> Message-ID: <1564944728.23.0.912872206259.issue36324@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 8183bb8150edcac6a7525bfb7708d08837ecb095 by Raymond Hettinger in branch 'master': bpo-36324: Update comments to include the target hash sums (GH-15110) https://github.com/python/cpython/commit/8183bb8150edcac6a7525bfb7708d08837ecb095 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 14:53:54 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 18:53:54 +0000 Subject: [issue36324] Inverse cumulative normal distribution function In-Reply-To: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org> Message-ID: <1564944834.99.0.796216972831.issue36324@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14854 pull_request: https://github.com/python/cpython/pull/15112 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 14:58:56 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Aug 2019 18:58:56 +0000 Subject: [issue28292] Make Calendar.itermonthdates() behave consistently in edge cases In-Reply-To: <1475031718.56.0.220203946513.issue28292@psf.upfronthosting.co.za> Message-ID: <1564945136.07.0.465901752125.issue28292@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +14855 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/15113 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 15:16:22 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Aug 2019 19:16:22 +0000 Subject: [issue36324] Inverse cumulative normal distribution function In-Reply-To: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org> Message-ID: <1564946182.76.0.779161116382.issue36324@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset d7d607c000a28432f87d24d2a5a9315c51017041 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-36324: Update comments to include the target hash sums (GH-15110) (GH-15112) https://github.com/python/cpython/commit/d7d607c000a28432f87d24d2a5a9315c51017041 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 15:26:39 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 04 Aug 2019 19:26:39 +0000 Subject: [issue34621] uuid.UUID objects can't be unpickled in older Python versions (<3.7) In-Reply-To: <1536581817.86.0.56676864532.issue34621@psf.upfronthosting.co.za> Message-ID: <1564946799.97.0.699484678446.issue34621@roundup.psfhosted.org> Tal Einat added the comment: New changeset a2ea9448c677706d6318eaa71101f08df7604eb9 by Tal Einat in branch '3.7': [3.7] bpo-34621: backwards-compatible pickle UUID with is_safe=unknown (GH-14834) https://github.com/python/cpython/commit/a2ea9448c677706d6318eaa71101f08df7604eb9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 15:27:26 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 04 Aug 2019 19:27:26 +0000 Subject: [issue1382562] --install-base not honored on win32 Message-ID: <1564946846.46.0.41303426816.issue1382562@roundup.psfhosted.org> Joannah Nanjekye added the comment: Similar to issue21710 ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 15:30:11 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 04 Aug 2019 19:30:11 +0000 Subject: [issue34621] uuid.UUID objects can't be unpickled in older Python versions (<3.7) In-Reply-To: <1536581817.86.0.56676864532.issue34621@psf.upfronthosting.co.za> Message-ID: <1564947011.21.0.791607411009.issue34621@roundup.psfhosted.org> Tal Einat added the comment: Note that the original fix, in PR GH-9133, contained a bug: UUID objects with `is_safe` set to `SafeUUID.unknown` would cause an exception if unpickled with Python <3.7. This was reported by Thomas Wiebe in a comment to a commit in that PR: https://github.com/python/cpython/commit/d53f1cabe8837697df4acb70c9c6537461b5eeda#commitcomment-31396021 This is now fixed, see PR GH-14834. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 15:54:22 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 04 Aug 2019 19:54:22 +0000 Subject: [issue37748] IDLE: Re-order run menu In-Reply-To: <1564807705.24.0.436490903651.issue37748@roundup.psfhosted.org> Message-ID: <1564948462.02.0.516219948251.issue37748@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- keywords: +patch pull_requests: +14856 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15115 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 16:14:13 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 20:14:13 +0000 Subject: [issue28292] Make Calendar.itermonthdates() behave consistently in edge cases In-Reply-To: <1475031718.56.0.220203946513.issue28292@psf.upfronthosting.co.za> Message-ID: <1564949653.36.0.754702501567.issue28292@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14857 pull_request: https://github.com/python/cpython/pull/15116 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 16:14:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Aug 2019 20:14:06 +0000 Subject: [issue28292] Make Calendar.itermonthdates() behave consistently in edge cases In-Reply-To: <1475031718.56.0.220203946513.issue28292@psf.upfronthosting.co.za> Message-ID: <1564949646.51.0.17320897065.issue28292@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset b1c8ec010fb4eb2654ca994e95144c8f2fea07fb by Raymond Hettinger in branch 'master': bpo-28292: Mark calendar.py helper functions as private. (GH-15113) https://github.com/python/cpython/commit/b1c8ec010fb4eb2654ca994e95144c8f2fea07fb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 16:21:23 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Aug 2019 20:21:23 +0000 Subject: [issue37646] eval() in a list comprehension In-Reply-To: <1563751465.46.0.439346831661.issue37646@roundup.psfhosted.org> Message-ID: <1564950083.92.0.549410603148.issue37646@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +14858 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/15117 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 16:27:54 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Aug 2019 20:27:54 +0000 Subject: [issue37646] eval() in a list comprehension In-Reply-To: <1563751465.46.0.439346831661.issue37646@roundup.psfhosted.org> Message-ID: <1564950474.03.0.326821516185.issue37646@roundup.psfhosted.org> Raymond Hettinger added the comment: After more thought, I think the existing behavior is probably what we want. There may not be a clean way to allow access and updates to non-locals. Even if a way was found, it may tie our hands and preclude other implementation changes down the road. Also, such a feature may be at odds with the current API which allows the execution environment to be retargeted. There is also a risk of introducing new security issues. I've attached a PR to update the eval() docs to reflect the actual behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 16:29:07 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Aug 2019 20:29:07 +0000 Subject: [issue28292] Make Calendar.itermonthdates() behave consistently in edge cases In-Reply-To: <1475031718.56.0.220203946513.issue28292@psf.upfronthosting.co.za> Message-ID: <1564950547.38.0.205078509985.issue28292@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 16:34:59 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Aug 2019 20:34:59 +0000 Subject: [issue28292] Make Calendar.itermonthdates() behave consistently in edge cases In-Reply-To: <1475031718.56.0.220203946513.issue28292@psf.upfronthosting.co.za> Message-ID: <1564950899.87.0.278481920014.issue28292@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 0c16f6b307f7607e29b98b8fbb99cbca28f91a48 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-28292: Mark calendar.py helper functions as private. (GH-15113) (GH-15116) https://github.com/python/cpython/commit/0c16f6b307f7607e29b98b8fbb99cbca28f91a48 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 16:45:18 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 04 Aug 2019 20:45:18 +0000 Subject: [issue37748] IDLE: Re-order run menu In-Reply-To: <1564807705.24.0.436490903651.issue37748@roundup.psfhosted.org> Message-ID: <1564951518.67.0.403123752308.issue37748@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset 14070299cdc0faf36975f0cc2d51824a9abf3db0 by Terry Jan Reedy in branch 'master': bpo-37748: Re-order the Run menu. (GH-15115) https://github.com/python/cpython/commit/14070299cdc0faf36975f0cc2d51824a9abf3db0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 16:45:26 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 20:45:26 +0000 Subject: [issue37748] IDLE: Re-order run menu In-Reply-To: <1564807705.24.0.436490903651.issue37748@roundup.psfhosted.org> Message-ID: <1564951526.68.0.455931434208.issue37748@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14859 pull_request: https://github.com/python/cpython/pull/15119 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 16:45:33 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 20:45:33 +0000 Subject: [issue37748] IDLE: Re-order run menu In-Reply-To: <1564807705.24.0.436490903651.issue37748@roundup.psfhosted.org> Message-ID: <1564951533.17.0.51402548367.issue37748@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14860 pull_request: https://github.com/python/cpython/pull/15120 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 16:47:29 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Sun, 04 Aug 2019 20:47:29 +0000 Subject: [issue35707] time.sleep() should support objects with __float__ In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org> Message-ID: <1564951649.87.0.0160893793181.issue35707@roundup.psfhosted.org> Jeroen Demeyer added the comment: > If we want to support other numerical types with loss in double rounding, the most reliable way is to represent them as fractions (x.as_integer_ratio() or (x.numerator, x.denominator)) See https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/24?u=jdemeyer for a proposal to define __ratio__ for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 17:04:53 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 21:04:53 +0000 Subject: [issue37748] IDLE: Re-order run menu In-Reply-To: <1564807705.24.0.436490903651.issue37748@roundup.psfhosted.org> Message-ID: <1564952693.08.0.423314058823.issue37748@roundup.psfhosted.org> miss-islington added the comment: New changeset 9c95fc752c1465202df67fa894ef326c8ebb8cac by Miss Islington (bot) in branch '3.8': bpo-37748: Re-order the Run menu. (GH-15115) https://github.com/python/cpython/commit/9c95fc752c1465202df67fa894ef326c8ebb8cac ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 17:07:28 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 21:07:28 +0000 Subject: [issue37748] IDLE: Re-order run menu In-Reply-To: <1564807705.24.0.436490903651.issue37748@roundup.psfhosted.org> Message-ID: <1564952848.89.0.383322732384.issue37748@roundup.psfhosted.org> miss-islington added the comment: New changeset a96f0367d4c84ed42f8dc80c88c10f334498f36c by Miss Islington (bot) in branch '3.7': bpo-37748: Re-order the Run menu. (GH-15115) https://github.com/python/cpython/commit/a96f0367d4c84ed42f8dc80c88c10f334498f36c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 17:23:04 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Sun, 04 Aug 2019 21:23:04 +0000 Subject: [issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc In-Reply-To: <1563731175.2.0.136240000148.issue37645@roundup.psfhosted.org> Message-ID: <1564953784.67.0.632651482557.issue37645@roundup.psfhosted.org> Jeroen Demeyer added the comment: Another solution would be to change the __str__ of various function objects to a prettier output. For example, we currently have >>> def f(): pass >>> print(f) We could change this to >>> def f(): pass >>> print(f) f() and then use "%S" to display the functions in error messages. But I have a feeling that this is a more controversial change than PR 14890. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 17:43:50 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 04 Aug 2019 21:43:50 +0000 Subject: [issue36419] IDLE autocomplete: refactor and polish code and tests In-Reply-To: <1553469085.88.0.432002901822.issue36419@roundup.psfhosted.org> Message-ID: <1564955030.66.0.486332753404.issue36419@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- keywords: +patch pull_requests: +14861 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/15121 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 17:46:11 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 04 Aug 2019 21:46:11 +0000 Subject: [issue37748] IDLE: Re-order run menu In-Reply-To: <1564807705.24.0.436490903651.issue37748@roundup.psfhosted.org> Message-ID: <1564955171.82.0.136545630906.issue37748@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 Aug 4 18:34:41 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 04 Aug 2019 22:34:41 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1564958081.34.0.74816029711.issue35892@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +14862 pull_request: https://github.com/python/cpython/pull/15122 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 19:49:01 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 04 Aug 2019 23:49:01 +0000 Subject: [issue36419] IDLE autocomplete: refactor and polish code and tests In-Reply-To: <1553469085.88.0.432002901822.issue36419@roundup.psfhosted.org> Message-ID: <1564962541.73.0.522363457451.issue36419@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset 1213123005d9f94bb5027c0a5256ea4d3e97b61d by Terry Jan Reedy in branch 'master': bpo-36419: IDLE - Refactor autocompete and improve testing. (#15121) https://github.com/python/cpython/commit/1213123005d9f94bb5027c0a5256ea4d3e97b61d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 19:49:07 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 23:49:07 +0000 Subject: [issue36419] IDLE autocomplete: refactor and polish code and tests In-Reply-To: <1553469085.88.0.432002901822.issue36419@roundup.psfhosted.org> Message-ID: <1564962547.39.0.641625632894.issue36419@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14863 pull_request: https://github.com/python/cpython/pull/15123 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 19:49:14 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 04 Aug 2019 23:49:14 +0000 Subject: [issue36419] IDLE autocomplete: refactor and polish code and tests In-Reply-To: <1553469085.88.0.432002901822.issue36419@roundup.psfhosted.org> Message-ID: <1564962554.39.0.468057426959.issue36419@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14864 pull_request: https://github.com/python/cpython/pull/15124 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 20:08:19 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 05 Aug 2019 00:08:19 +0000 Subject: [issue36419] IDLE autocomplete: refactor and polish code and tests In-Reply-To: <1553469085.88.0.432002901822.issue36419@roundup.psfhosted.org> Message-ID: <1564963699.89.0.826465320138.issue36419@roundup.psfhosted.org> miss-islington added the comment: New changeset 5349f8cd784220fc6599830c56d3f0614de2b8cb by Miss Islington (bot) in branch '3.8': bpo-36419: IDLE - Refactor autocompete and improve testing. (GH-15121) https://github.com/python/cpython/commit/5349f8cd784220fc6599830c56d3f0614de2b8cb ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 20:09:40 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 05 Aug 2019 00:09:40 +0000 Subject: [issue36419] IDLE autocomplete: refactor and polish code and tests In-Reply-To: <1553469085.88.0.432002901822.issue36419@roundup.psfhosted.org> Message-ID: <1564963780.11.0.969201171782.issue36419@roundup.psfhosted.org> miss-islington added the comment: New changeset 4969192f99046bc0f6453185082c00f7a6e132ec by Miss Islington (bot) in branch '3.7': bpo-36419: IDLE - Refactor autocompete and improve testing. (GH-15121) https://github.com/python/cpython/commit/4969192f99046bc0f6453185082c00f7a6e132ec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 20:13:10 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 05 Aug 2019 00:13:10 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1564963990.61.0.563482750995.issue35224@roundup.psfhosted.org> Nick Coghlan added the comment: Did the documentation PR get pushed/merged? Emily mentioned having one in progress above, but it doesn't appear in the linked PRs. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 20:15:02 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 05 Aug 2019 00:15:02 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict Message-ID: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> New submission from Nick Coghlan : While implementing PEP 572, Emily noted that the check for conflicts between assignment operators and comprehension iteration variables had not yet been implemented: https://bugs.python.org/issue35224#msg334331 Damien George came across this discrepancy while implementing assignment expressions for MicroPython. The proposed discussion regarding whether or not the PEP should be changed didn't happen, and the PEP itself misses the genuinely confusing cases where even an assignment expression that *never executes* will still make the iteration variable leak: >>> [i for i in range(5)] [0, 1, 2, 3, 4] >>> [i := 10 for i in range(5)] [10, 10, 10, 10, 10] >>> i 10 >>> [False and (i := 10) for i in range(5)] [False, False, False, False, False] >>> i 4 And that side effect happens even if the assignment expression is nested further down in an inner loop: >>> [(i, j, k) for i in range(2) for j in range(2) for k in range(2)] [(0, 0, 0), (0, 0, 1), (0, 1, 0), (0, 1, 1), (1, 0, 0), (1, 0, 1), (1, 1, 0), (1, 1, 1)] >>> i Traceback (most recent call last): File "", line 1, in NameError: name 'i' is not defined >>> [(i, j, k) for i in range(2) for j in range(2) for k in range(2) if True or (i:=10)] [(0, 0, 0), (0, 0, 1), (0, 1, 0), (0, 1, 1), (1, 0, 0), (1, 0, 1), (1, 1, 0), (1, 1, 1)] >>> i 1 I'm at the PyCon AU sprints today, and will be working on a PR to make these cases raise TargetScopeError as specified in the PEP. ---------- assignee: ncoghlan messages: 349012 nosy: Damien George, emilyemorehouse, ncoghlan priority: deferred blocker severity: normal stage: needs patch status: open title: TargetScopeError not raised for comprehension scope conflict type: behavior versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 20:16:11 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 05 Aug 2019 00:16:11 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1564964171.4.0.941734473833.issue35224@roundup.psfhosted.org> Nick Coghlan added the comment: https://bugs.python.org/issue37757 separates out the TargetScopeError handling for conflicts between assignment expressions and comprehension iteration variables. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 21:06:02 2019 From: report at bugs.python.org (Greg Price) Date: Mon, 05 Aug 2019 01:06:02 +0000 Subject: [issue37758] unicodedata checksum-tests only test 1/17th of Unicode's codepoints Message-ID: <1564967162.48.0.525882022653.issue37758@roundup.psfhosted.org> New submission from Greg Price : The unicodedata module has two test cases which run through the database and make a hash of its visible outputs for all codepoints, comparing the hash against a checksum. These are helpful regression tests for making sure the behavior isn't changed by patches that didn't intend to change it. But Unicode has grown since Python first gained support for it, when Unicode itself was still rather new. These test cases were added in commit 6a20ee7de back in 2000, and they haven't needed to change much since then... but they should be changed to look beyond the Basic Multilingual Plane (`range(0x10000)`) and cover all 17 planes of Unicode's final form. Spotted in discussion on GH-15019 (https://github.com/python/cpython/pull/15019#discussion_r308947884 ). I have a patch for this which I'll send shortly. ---------- components: Tests messages: 349014 nosy: Greg Price priority: normal severity: normal status: open title: unicodedata checksum-tests only test 1/17th of Unicode's codepoints type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 21:09:02 2019 From: report at bugs.python.org (Greg Price) Date: Mon, 05 Aug 2019 01:09:02 +0000 Subject: [issue37758] unicodedata checksum-tests only test 1/17th of Unicode's codepoints In-Reply-To: <1564967162.48.0.525882022653.issue37758@roundup.psfhosted.org> Message-ID: <1564967342.77.0.490343540904.issue37758@roundup.psfhosted.org> Change by Greg Price : ---------- keywords: +patch pull_requests: +14865 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15125 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 21:09:57 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 05 Aug 2019 01:09:57 +0000 Subject: [issue36419] IDLE autocomplete: refactor and polish code and tests In-Reply-To: <1553469085.88.0.432002901822.issue36419@roundup.psfhosted.org> Message-ID: <1564967397.91.0.302893143451.issue36419@roundup.psfhosted.org> Terry J. Reedy added the comment: All three goals done. Most or all of the 7% not covered is the part of the file I did not touch. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 21:15:10 2019 From: report at bugs.python.org (Greg Price) Date: Mon, 05 Aug 2019 01:15:10 +0000 Subject: [issue37758] unicodedata checksum-tests only test 1/17th of Unicode's codepoints In-Reply-To: <1564967162.48.0.525882022653.issue37758@roundup.psfhosted.org> Message-ID: <1564967710.66.0.708263303158.issue37758@roundup.psfhosted.org> Change by Greg Price : ---------- pull_requests: +14866 pull_request: https://github.com/python/cpython/pull/15126 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 21:22:25 2019 From: report at bugs.python.org (Greg Price) Date: Mon, 05 Aug 2019 01:22:25 +0000 Subject: [issue37758] unicodedata checksum-tests only test 1/17th of Unicode's codepoints In-Reply-To: <1564967162.48.0.525882022653.issue37758@roundup.psfhosted.org> Message-ID: <1564968145.22.0.152496271081.issue37758@roundup.psfhosted.org> Greg Price added the comment: Sent two small PRs! The first one, GH-15125, makes the substantive test change I described above. The second one, GH-15126, is a small pure refactor to that test file, just cleaning out some bits that made sense when it was first written (as a script) but are confusing now that it's a `unittest` test module. Took me a couple of minutes to sort those out when I first dug into this file, and I figure it'd be kind to the next person to save them the same effort. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 21:32:23 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 05 Aug 2019 01:32:23 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1564968743.13.0.418960552706.issue35224@roundup.psfhosted.org> Nick Coghlan added the comment: Also, a major procedural note: it is NOT OK to merge a PEP implementation that completely ignores parts of the PEP. The merged tests are actively forcing NON-compliance with the accepted PEP, since they're requiring implementations to accept code that the PEP explicitly states should be disallowed. Those rules were added because the behaviour in CPython leaks CPython implementation details that we *don't want* to be part of the language specification. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 22:19:51 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 05 Aug 2019 02:19:51 +0000 Subject: [issue37759] Polish whatsnew for 3.8 Message-ID: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org> New submission from Raymond Hettinger : Beginning significant edits to whatsnew, adding examples and motivations, improving organization and clarity. Work in progress. ---------- assignee: rhettinger components: Documentation messages: 349018 nosy: rhettinger priority: high severity: normal status: open title: Polish whatsnew for 3.8 versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 22:23:32 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 05 Aug 2019 02:23:32 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1564971812.81.0.623142268144.issue35224@roundup.psfhosted.org> Raymond Hettinger added the comment: FWIW, I'm working on an improved whatsnew entry in https://github.com/python/cpython/pull/15127 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 22:26:07 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 05 Aug 2019 02:26:07 +0000 Subject: [issue37759] Polish whatsnew for 3.8 In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org> Message-ID: <1564971967.03.0.00178593161147.issue37759@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +14867 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15127 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 4 23:55:35 2019 From: report at bugs.python.org (Greg Price) Date: Mon, 05 Aug 2019 03:55:35 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass Message-ID: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> New submission from Greg Price : I spent some time yesterday on #18236, and I have a patch for it. Most of that work happens in the script Tools/unicode/makeunicode.py , and along the way I made several changes there that I found made it somewhat nicer to work on, and I think will help other people reading that script too. I'd like to try to merge those improvements first. The main changes are: * As the script has grown over the years, it's gained many copies and reimplementations of logic to parse the standard format of the Unicode character database. I factored those out into a single place, which makes the parsing code shorter and the interesting parts stand out more easily. * The main per-character record type in the script's data structures is a length-18 tuple. Using the magic of dataclasses, I converted this so that e.g. the code says `record.numeric_value` instead of `record[8]`. There's no radical restructuring or rewrite here; this script has served us well. I've kept these changes focused where there's a high ratio of value, in future ease of development, to cost, in a reviewer's effort as well as mine. I'll send PRs of my changes shortly. ---------- components: Unicode messages: 349020 nosy: Greg Price, ezio.melotti, vstinner priority: normal severity: normal status: open title: Refactor makeunicodedata.py: dedupe parsing, use dataclass type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 00:00:50 2019 From: report at bugs.python.org (Greg Price) Date: Mon, 05 Aug 2019 04:00:50 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1564977650.73.0.855772882106.issue37760@roundup.psfhosted.org> Change by Greg Price : ---------- keywords: +patch pull_requests: +14868 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15128 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 00:04:27 2019 From: report at bugs.python.org (Greg Price) Date: Mon, 05 Aug 2019 04:04:27 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1564977867.87.0.115389677181.issue37760@roundup.psfhosted.org> Change by Greg Price : ---------- pull_requests: +14869 pull_request: https://github.com/python/cpython/pull/15129 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 00:07:35 2019 From: report at bugs.python.org (Greg Price) Date: Mon, 05 Aug 2019 04:07:35 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1564978055.28.0.197187760779.issue37760@roundup.psfhosted.org> Change by Greg Price : ---------- pull_requests: +14870 pull_request: https://github.com/python/cpython/pull/15130 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 00:15:06 2019 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Aug 2019 04:15:06 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1564978506.75.0.3516829552.issue35224@roundup.psfhosted.org> Guido van Rossum added the comment: Thanks for catching that this was still incomplete. > Also, a major procedural note: it is NOT OK to merge a PEP implementation that completely ignores parts of the PEP. The merged tests are actively forcing NON-compliance with the accepted PEP, since they're requiring implementations to accept code that the PEP explicitly states should be disallowed. It was known the implementation was unfinished in this respect, but it was deemed better to merge what we had lest the work be lost in merge conflicts, and iterate in later betas. I've written some code that uses the walrus operator and have found it quite solid. The early existence of an implementation (albeit incomplete) has also helped get support for this in mypy (https://github.com/python/mypy/pull/6899). I don't recall being aware that there were tests that specifically *checked* that the implementation was incomplete, and that's obviously wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 00:15:46 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 05 Aug 2019 04:15:46 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1564978546.79.0.942101835551.issue37757@roundup.psfhosted.org> Change by Nick Coghlan : ---------- keywords: +patch pull_requests: +14871 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15131 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 00:23:52 2019 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Aug 2019 04:23:52 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1564979032.5.0.459513394166.issue37757@roundup.psfhosted.org> Guido van Rossum added the comment: Thanks for being part of the village raising this child! ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 00:25:24 2019 From: report at bugs.python.org (Greg Price) Date: Mon, 05 Aug 2019 04:25:24 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1564979124.61.0.511224593757.issue37760@roundup.psfhosted.org> Greg Price added the comment: Just posted three PRs: * GH-15128 and GH-15129 are both quite small * GH-15130 is the first of two patches factoring out common parsing logic. Two remaining patches go on top of GH-15130. Here are drafts, in case they're helpful for reference: * Patch 2/2 factoring out common parsing logic: https://github.com/gnprice/cpython/commit/0a32a7111 * Patch converting the big tuples to a dataclass: https://github.com/gnprice/cpython/commit/6d8103bbc I figure they may be easiest to review after the PR they depend on is merged, so my plan is to send PRs for them each in turn. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 00:32:26 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 05 Aug 2019 04:32:26 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1564979546.23.0.674845869275.issue35224@roundup.psfhosted.org> Nick Coghlan added the comment: #37757 now has an associated PR adding the missing TargetScopeError cases: https://github.com/python/cpython/pull/15131 There's one case where it goes beyond what the PEP specifies: because the outermost iterable expression gets evaluated in a different scope from the rest of the comprehension, it just flat out prohibits the use of assignment expressions in comprehension iterable expressions. This was one of the cases where we explicitly didn't want the CPython implementation behaviour to leak into the language specification (as name binding in the outermost iterable expression would create an unrelated binding in the containing scope, while name binding in other iterable expressions would rebind any conflicting iteration variable in the comprehension), so the current PR takes the more conservative path, and defers allowing name binding in the iterable expressions until a specific use case for doing so is presented). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 00:36:52 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 05 Aug 2019 04:36:52 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1564979812.19.0.296945997043.issue35224@roundup.psfhosted.org> Nick Coghlan added the comment: Thanks Guido. The former test cases that the new PR removes are the following: res = [i := i for i in range(5)] res = [i := 0 for i, j in [(1, 2), (3, 4)]] res = [(i := 0, j := 1) for i, j in [(1, 2), (3, 4)]] res = [(i := i, j := j) for i, j in [(1, 2), (3, 4)]] res = [(i := j, j := i) for i, j in [(1, 2), (3, 4)]] These all raise TargetScopeError with the PR applied: >>> res = [i := i for i in range(5)] File "", line 1 TargetScopeError: named expression cannot rebind comprehension iteration variable >>> res = [i := 0 for i, j in [(1, 2), (3, 4)]] File "", line 1 TargetScopeError: named expression cannot rebind comprehension iteration variable >>> res = [(i := 0, j := 1) for i, j in [(1, 2), (3, 4)]] File "", line 1 TargetScopeError: named expression cannot rebind comprehension iteration variable >>> res = [(i := i, j := j) for i, j in [(1, 2), (3, 4)]] File "", line 1 TargetScopeError: named expression cannot rebind comprehension iteration variable >>> res = [(i := j, j := i) for i, j in [(1, 2), (3, 4)]] File "", line 1 TargetScopeError: named expression cannot rebind comprehension iteration variable ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 00:49:30 2019 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Aug 2019 04:49:30 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1564979812.19.0.296945997043.issue35224@roundup.psfhosted.org> Message-ID: Guido van Rossum added the comment: Can you suggest a PEP update too, for the case that goes beyond the PEP? And please provide examples (not everybody knows immediately what "outermost iterable expression" refers to. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 01:29:05 2019 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 05 Aug 2019 05:29:05 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1564982945.91.0.737236761282.issue32912@roundup.psfhosted.org> Nathaniel Smith added the comment: I think we haven't *actually* done a proper DeprecationWarning period for this. We tried, but because of the issue with byte-compiling, the warnings were unconditionally suppressed for most users -- even the users who are diligent enough to enable warnings and look at warnings in their test suites. I can see a good argument for making the change, but if we're going to do it then it's obviously the kind of change that requires a proper deprecation period, and that hasn't happened. Maybe .pyc files need to be extended to store a list of syntax-related DeprecationWarnings and SyntaxWarnings, that are re-issued every time the .pyc is loaded? Then we'd at least have the technical capability to deprecate this properly. ---------- nosy: +njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 02:20:28 2019 From: report at bugs.python.org (Andrew Yurisich) Date: Mon, 05 Aug 2019 06:20:28 +0000 Subject: [issue37623] namedtuple integration for importlib.abc.Loader In-Reply-To: <1563476843.29.0.0326918684988.issue37623@roundup.psfhosted.org> Message-ID: <1564986028.71.0.730953587939.issue37623@roundup.psfhosted.org> Andrew Yurisich added the comment: If anyone is interested in the progress I was able to make as a result of this discussion, feel free to check out https://github.com/captain-kark/python-module-resources/blob/d85453ff4f5022127874a5842449d95bb5eda234/module_resources/module_resources.py and leave you feedback or comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 02:49:27 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 05 Aug 2019 06:49:27 +0000 Subject: [issue19692] Rename Py_SAFE_DOWNCAST In-Reply-To: <1385130295.49.0.846468108755.issue19692@psf.upfronthosting.co.za> Message-ID: <1564987767.62.0.702220936728.issue19692@roundup.psfhosted.org> Inada Naoki added the comment: While Py_SAFE_DOWNCAST is not documented, it doesn't start with underscore. How many 3rd party code are broken by changing the name? ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 03:20:41 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 05 Aug 2019 07:20:41 +0000 Subject: [issue37729] gc: stats from multi process are mixed up In-Reply-To: <1564565728.92.0.202188074199.issue37729@roundup.psfhosted.org> Message-ID: <1564989641.76.0.70998104384.issue37729@roundup.psfhosted.org> Inada Naoki added the comment: New changeset e8ea34855c7635f8a84b430f17dc01a666f4c0ef by Inada Naoki (Miss Islington (bot)) in branch '3.8': bpo-37729: gc: write stats at once (GH-15050) https://github.com/python/cpython/commit/e8ea34855c7635f8a84b430f17dc01a666f4c0ef ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 03:21:27 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 05 Aug 2019 07:21:27 +0000 Subject: [issue37729] gc: stats from multi process are mixed up In-Reply-To: <1564565728.92.0.202188074199.issue37729@roundup.psfhosted.org> Message-ID: <1564989687.59.0.921392163017.issue37729@roundup.psfhosted.org> Change by Inada Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 03:23:40 2019 From: report at bugs.python.org (Tatsuo Sekine) Date: Mon, 05 Aug 2019 07:23:40 +0000 Subject: [issue37761] Inaccurate explanation of ArgumentParser.add_argument()'s name-or-flags in JA Message-ID: <1564989820.31.0.707943982318.issue37761@roundup.psfhosted.org> New submission from Tatsuo Sekine : Second sentence of name-or-flags explanation of argparse.ArgumentParser.add_argument() in ja lang. is: > ?????add_argument() ??1???????????????????????????????? #[1] while its original English is: > The first arguments passed to add_argument() must therefore be either a series of flags, or a simple argument name. # [2] If I translate Japanese language one back to English, it'd be something: The first argument passed to add_argument() must therefore be either a list of flags, or a simple argument name. Japanese one's explanation means, name-or-flags could be either - "name" - ["-f", "--flag"] So, Japanese translation could be improved to clarify that name-of-flags (i.e. first argument*s*) could be either name or *series* (not list) of flags. Note that, following sentences in the doc have many supporting explanations, and also, there is argparse HOWTO doc with many examples, so this is not critical issue at all. [1] https://docs.python.org/ja/3/library/argparse.html#name-or-flags [2] https://docs.python.org/3/library/argparse.html#name-or-flags ---------- assignee: docs at python components: Documentation messages: 349031 nosy: Tatsuo Sekine, docs at python priority: normal severity: normal status: open title: Inaccurate explanation of ArgumentParser.add_argument()'s name-or-flags in JA type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 03:27:13 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 05 Aug 2019 07:27:13 +0000 Subject: [issue37761] Inaccurate explanation of ArgumentParser.add_argument()'s name-or-flags in JA In-Reply-To: <1564989820.31.0.707943982318.issue37761@roundup.psfhosted.org> Message-ID: <1564990033.7.0.495038271709.issue37761@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Japanese translation is tracked as part of GitHub issues at https://github.com/python/python-docs-ja . ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 03:34:44 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 05 Aug 2019 07:34:44 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1564990484.9.0.104492422112.issue37757@roundup.psfhosted.org> Nick Coghlan added the comment: Added a PEP update as well: https://github.com/python/peps/pull/1140 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 03:36:24 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 05 Aug 2019 07:36:24 +0000 Subject: [issue37761] Inaccurate explanation of ArgumentParser.add_argument()'s name-or-flags in JA In-Reply-To: <1564989820.31.0.707943982318.issue37761@roundup.psfhosted.org> Message-ID: <1564990584.47.0.895503038325.issue37761@roundup.psfhosted.org> Change by Inada Naoki : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 03:37:17 2019 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 05 Aug 2019 07:37:17 +0000 Subject: [issue35224] PEP 572: Assignment Expressions In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za> Message-ID: <1564990637.43.0.0317449745862.issue35224@roundup.psfhosted.org> Nick Coghlan added the comment: Proposed PEP update is here: https://github.com/python/peps/pull/1140 The update also aims to clarify *why* we're doing the extra work in CPython's compiler to make these cases fail (i.e. we don't want to implicitly impose the current CPython runtime behaviour on other implementations) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 04:26:43 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 08:26:43 +0000 Subject: [issue36773] Race condition during pickle.load() In-Reply-To: <1556785499.96.0.563265579216.issue36773@roundup.psfhosted.org> Message-ID: <1564993603.14.0.831757676247.issue36773@roundup.psfhosted.org> Tal Einat added the comment: On Windows 10, this reproduces consistently with 3.6 and 3.7.0, but not with 3.7.4, 3.8.0b3 and current master. So this definitely seems to be fixed. ---------- nosy: +taleinat resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 04:38:26 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 08:38:26 +0000 Subject: [issue12680] cPickle.loads is not thread safe due to non-thread-safe imports In-Reply-To: <1312272969.55.0.673755441724.issue12680@psf.upfronthosting.co.za> Message-ID: <1564994306.89.0.240094546778.issue12680@roundup.psfhosted.org> Tal Einat added the comment: I am able to reproduce this with Python 3.6.3 and 3.7.0, but not with 3.7.4, 3.8.0b3 or current master (to be 3.9). This has been fixed since 3.7.3; see issue #34572. ---------- nosy: +taleinat resolution: not a bug -> fixed stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 05:04:19 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Mon, 05 Aug 2019 09:04:19 +0000 Subject: [issue28716] Fractions instantiation revisited In-Reply-To: <1479319587.68.0.845103759053.issue28716@psf.upfronthosting.co.za> Message-ID: <1564995859.26.0.840294179916.issue28716@roundup.psfhosted.org> Jeroen Demeyer added the comment: See https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/24?u=jdemeyer for a proposal to define a new dunder __ratio__ (instead of as_integer_ratio) for this. ---------- nosy: +jdemeyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 05:06:17 2019 From: report at bugs.python.org (David Heiberg) Date: Mon, 05 Aug 2019 09:06:17 +0000 Subject: [issue37730] NotImplemented is used instead of NotImplementedError in docs In-Reply-To: <1564576160.73.0.181501805035.issue37730@roundup.psfhosted.org> Message-ID: <1564995977.25.0.478223378505.issue37730@roundup.psfhosted.org> Change by David Heiberg : ---------- pull_requests: +14872 pull_request: https://github.com/python/cpython/pull/15133 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 05:19:32 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 05 Aug 2019 09:19:32 +0000 Subject: [issue37730] NotImplemented is used instead of NotImplementedError in docs In-Reply-To: <1564576160.73.0.181501805035.issue37730@roundup.psfhosted.org> Message-ID: <1564996772.68.0.884432317334.issue37730@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 35f9bccd8198330579ecb4b4c503062f8b5da130 by Serhiy Storchaka (David H) in branch '2.7': [2.7] bpo-37730: Fix usage of NotImplemented instead of NotImplementedError in docs. (GH-15062). (GH-15133) https://github.com/python/cpython/commit/35f9bccd8198330579ecb4b4c503062f8b5da130 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 05:20:17 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 05 Aug 2019 09:20:17 +0000 Subject: [issue37730] NotImplemented is used instead of NotImplementedError in docs In-Reply-To: <1564576160.73.0.181501805035.issue37730@roundup.psfhosted.org> Message-ID: <1564996817.58.0.055607275584.issue37730@roundup.psfhosted.org> Serhiy Storchaka added the comment: Thank you for your contribution David! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 05:22:27 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 05 Aug 2019 09:22:27 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1564996947.6.0.927565339725.issue37757@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 05:53:59 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 05 Aug 2019 09:53:59 +0000 Subject: [issue37587] JSON loads performance improvement for long strings In-Reply-To: <1563028922.54.0.821649437171.issue37587@roundup.psfhosted.org> Message-ID: <1564998839.63.0.69012294024.issue37587@roundup.psfhosted.org> Inada Naoki added the comment: I tried without PGO and confirmed performance improved on GCC 7.2.0. No change on other compiler versions. $ ./python -m pyperf timeit -s "import json; x = json.dumps({'k': '1' * 2 ** 20})" "json.loads(x)" old: 9211e2 new: 8a758f gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0 old: Mean +- std dev: 721 us +- 0 us new: Mean +- std dev: 722 us +- 0 us gcc-7 (Ubuntu 7.4.0-8ubuntu1) 7.4.0 old: Mean +- std dev: 1.03 ms +- 0.00 ms new: Mean +- std dev: 726 us +- 0 us clang version 7.0.1-8 (tags/RELEASE_701/final) old: Mean +- std dev: 721 us +- 1 us new: Mean +- std dev: 722 us +- 0 us clang version 8.0.0-3 (tags/RELEASE_800/final) old: Mean +- std dev: 721 us +- 0 us new: Mean +- std dev: 721 us +- 1 us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 05:57:44 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 09:57:44 +0000 Subject: [issue36756] tkinter tk.createcommand memory leak In-Reply-To: <1556615385.08.0.753953745903.issue36756@roundup.psfhosted.org> Message-ID: <1564999064.46.0.759319124364.issue36756@roundup.psfhosted.org> Tal Einat added the comment: Tkinter calls Tcl_DeleteInterp when a Tk object is garbage collected, and it registers a cleanup callback for each registered command, which according to the Tcl docs should be called upon Tcl_DeleteInterp[1]. So this must either be a bug in Tcl or something in the circumstances isn't giving it a chance to clean up the commands. It's worth noting that Tk.destroy() calls Misc.destroy() which explicitly calls deletecommand for all registered commands. So calling .destroy() when done with a Tk instance, which is good practice in general, will also avoid this issue. Considering the above, I'm not sure this is worth investigating and addressing... A simple solution could be to add __del__ to Tk or Misc and have that also clean up any registered commands. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 06:01:23 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 05 Aug 2019 10:01:23 +0000 Subject: [issue37587] JSON loads performance improvement for long strings In-Reply-To: <1563028922.54.0.821649437171.issue37587@roundup.psfhosted.org> Message-ID: <1564999283.25.0.883386513696.issue37587@roundup.psfhosted.org> Change by Inada Naoki : ---------- pull_requests: +14873 pull_request: https://github.com/python/cpython/pull/15134 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 06:02:50 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 05 Aug 2019 10:02:50 +0000 Subject: [issue37587] JSON loads performance improvement for long strings In-Reply-To: <1563028922.54.0.821649437171.issue37587@roundup.psfhosted.org> Message-ID: <1564999370.38.0.459446423997.issue37587@roundup.psfhosted.org> Inada Naoki added the comment: And I confirmed performance improvement by my patch (GH-15134) on all of 4 compilers. $ ./python -m pyperf timeit -s "import json; x = json.dumps({'k': '1' * 2 ** 20})" "json.loads(x)" old: 9211e2 new: 8a758f opt2: 284e47 gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0 old: Mean +- std dev: 721 us +- 0 us new: Mean +- std dev: 722 us +- 0 us opt2: Mean +- std dev: 715 us +- 1 us gcc-7 (Ubuntu 7.4.0-8ubuntu1) 7.4.0 old: Mean +- std dev: 1.03 ms +- 0.00 ms new: Mean +- std dev: 726 us +- 0 us opt2: Mean +- std dev: 715 us +- 0 us clang version 7.0.1-8 (tags/RELEASE_701/final) old: Mean +- std dev: 721 us +- 1 us new: Mean +- std dev: 722 us +- 0 us opt2: Mean +- std dev: 715 us +- 1 us clang version 8.0.0-3 (tags/RELEASE_800/final) old: Mean +- std dev: 721 us +- 0 us new: Mean +- std dev: 721 us +- 1 us opt2: Mean +- std dev: 715 us +- 0 us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 06:06:02 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 10:06:02 +0000 Subject: [issue36767] Segmentation fault when running c extension on macOS In-Reply-To: <1556718597.1.0.626589085866.issue36767@roundup.psfhosted.org> Message-ID: <1564999562.83.0.612960651833.issue36767@roundup.psfhosted.org> Tal Einat added the comment: I'm closing this: It has had no followup in over 3 months, and seems to be a simple misuse of the C API rather than a bug. ---------- nosy: +taleinat stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 06:20:22 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Mon, 05 Aug 2019 10:20:22 +0000 Subject: [issue37562] PEP 590 implementation may have introduced a performance regression In-Reply-To: <1562844416.61.0.409622240812.issue37562@roundup.psfhosted.org> Message-ID: <1565000422.44.0.884295948536.issue37562@roundup.psfhosted.org> Jeroen Demeyer added the comment: Please close ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 06:21:04 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 10:21:04 +0000 Subject: [issue36757] uuid constructor accept invalid strings (extra dash) In-Reply-To: <1556615988.91.0.308330120393.issue36757@roundup.psfhosted.org> Message-ID: <1565000464.03.0.831371056073.issue36757@roundup.psfhosted.org> Tal Einat added the comment: I too find this surprising, especially given how thoroughly UUID validates inputs of types other than "hex". The documentation simply states that for hex input, hypens, curly braces and a URN prefix are optional. In practice, though, it is much more lenient than that, as described here. Since the UUID has no expert listed, we'll have to decide whether to make the input validation stricter and break backwards-compatibility, or simply make the docs clearer. Clarifying the docs certainly seems simpler, safer and more user-friendly. It also seems reasonable, given that this issue apparently hasn't affected many users. ---------- nosy: +taleinat type: -> behavior versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 06:21:36 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Mon, 05 Aug 2019 10:21:36 +0000 Subject: [issue36974] Implement PEP 590 In-Reply-To: <1559154718.16.0.347735090162.issue36974@roundup.psfhosted.org> Message-ID: <1565000496.12.0.178368786122.issue36974@roundup.psfhosted.org> Jeroen Demeyer added the comment: > Should we add a note like "if you get a 'SystemError: bad call flags' on import, check the descriptor flags of your functions" in What's New in Python 3.8? A better solution would be to change the error message. We could change it to something like SystemError("bad flags 0x2 for PyCOMPS_categories_match") But maybe it's not worth it. Are there many projects that define functions/methods but never call them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 06:55:12 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 05 Aug 2019 10:55:12 +0000 Subject: [issue37562] PEP 590 implementation may have introduced a performance regression In-Reply-To: <1562844416.61.0.409622240812.issue37562@roundup.psfhosted.org> Message-ID: <1565002512.3.0.714089018458.issue37562@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 Aug 5 07:45:40 2019 From: report at bugs.python.org (Jordon.X) Date: Mon, 05 Aug 2019 11:45:40 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in some files In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1565005540.61.0.819299451236.issue37752@roundup.psfhosted.org> Jordon.X <9651234 at qq.com> added the comment: After the full search for the project code, there are more than a dozen similar issues that need to be modified. A new PR will be added later. ---------- title: Redundant Py_CHARMASK called in normalizestring(codecs.c) -> Redundant Py_CHARMASK called in some files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 08:13:55 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Mon, 05 Aug 2019 12:13:55 +0000 Subject: [issue33829] C API: provide new object protocol helper In-Reply-To: <1528710870.35.0.592728768989.issue33829@psf.upfronthosting.co.za> Message-ID: <1565007235.32.0.172002429009.issue33829@roundup.psfhosted.org> Jeroen Demeyer added the comment: I agree with rejecting and closing this issue. ---------- nosy: +jdemeyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 08:51:57 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 05 Aug 2019 12:51:57 +0000 Subject: [issue33829] C API: provide new object protocol helper In-Reply-To: <1528710870.35.0.592728768989.issue33829@psf.upfronthosting.co.za> Message-ID: <1565009517.63.0.0474053832193.issue33829@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 09:49:10 2019 From: report at bugs.python.org (hai shi) Date: Mon, 05 Aug 2019 13:49:10 +0000 Subject: [issue19692] Rename Py_SAFE_DOWNCAST In-Reply-To: <1385130295.49.0.846468108755.issue19692@psf.upfronthosting.co.za> Message-ID: <1565012950.04.0.297751921023.issue19692@roundup.psfhosted.org> hai shi added the comment: It's a big problem, no ability to answer this question :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 10:11:00 2019 From: report at bugs.python.org (Bernhard Hiller) Date: Mon, 05 Aug 2019 14:11:00 +0000 Subject: [issue37762] IDLE very slow due to special characters Message-ID: <1565014260.07.0.714424226111.issue37762@roundup.psfhosted.org> New submission from Bernhard Hiller : After installing tensorflow, I tried to run the demo script found at https://www.tensorflow.org/tutorials? In a common python shell, the "model.fit(x_train, y_train, epochs=5)" step takes a few minutes. In IDLE, no end is in sight after half an hour. While the output looks normal in the common shell, IDLE shows some control characters (see attached screenshot). Windows Task Managers shows a "pythonw.exe" process taking up 25% of CPU (i.e. 1 of 4 cores). ---------- assignee: terry.reedy components: IDLE files: Python374-3.PNG messages: 349050 nosy: Bernie, terry.reedy priority: normal severity: normal status: open title: IDLE very slow due to special characters type: performance versions: Python 3.7 Added file: https://bugs.python.org/file48530/Python374-3.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 10:39:45 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 05 Aug 2019 14:39:45 +0000 Subject: [issue33997] multiprocessing Pool hangs in terminate() In-Reply-To: <1530275873.32.0.56676864532.issue33997@psf.upfronthosting.co.za> Message-ID: <1565015985.21.0.0716946263056.issue33997@roundup.psfhosted.org> R?mi Lapeyre added the comment: Hi, I got bit by this bug last week, I wrote an example that reproduce the basic idea of our program main loop and it hangs - around 20% of the time with a release build of Python 3.7.4 - around 6% of the time with a debug build of Python 3.7, 3.8 and 3.9 With some of our inputs, it hangs nearly all the time but I cannot post them here. I tested PR 8009 and it solves the issue. It seems to me that it is an appropriate fix for this. ---------- Added file: https://bugs.python.org/file48531/multiprocessing_hangs.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 10:41:20 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 05 Aug 2019 14:41:20 +0000 Subject: [issue33997] multiprocessing Pool hangs in terminate() In-Reply-To: <1530275873.32.0.56676864532.issue33997@psf.upfronthosting.co.za> Message-ID: <1565016080.96.0.80436740018.issue33997@roundup.psfhosted.org> R?mi Lapeyre added the comment: Removed Python 3.6 as it is in security fixes now. ---------- versions: +Python 3.8, Python 3.9 -Python 3.6 Added file: https://bugs.python.org/file48532/test_multiprocessing.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 10:41:34 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Mon, 05 Aug 2019 14:41:34 +0000 Subject: [issue33997] multiprocessing Pool hangs in terminate() In-Reply-To: <1530275873.32.0.56676864532.issue33997@psf.upfronthosting.co.za> Message-ID: <1565016094.66.0.477397889218.issue33997@roundup.psfhosted.org> Change by R?mi Lapeyre : ---------- components: +Library (Lib) -Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 10:54:56 2019 From: report at bugs.python.org (Michael Felt) Date: Mon, 05 Aug 2019 14:54:56 +0000 Subject: [issue35545] asyncio.base_events.create_connection doesn't handle scoped IPv6 addresses In-Reply-To: <1545303410.27.0.788709270274.issue35545@psf.upfronthosting.co.za> Message-ID: <1565016896.67.0.28392755947.issue35545@roundup.psfhosted.org> Michael Felt added the comment: I did not ask back in June - but could this also be backported to 3.7. I am trying very hard to have all tests also passing on 3.7. as @asvetlov is ok with a skipped test for AIX - see https://bugs.python.org/issue35545#msg344003 I can make the backport, if needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 11:10:05 2019 From: report at bugs.python.org (Johan Herland) Date: Mon, 05 Aug 2019 15:10:05 +0000 Subject: [issue37763] Need setup.py to pick up -isystem flags from CPPFLAGS Message-ID: <1565017805.25.0.745177625686.issue37763@roundup.psfhosted.org> New submission from Johan Herland : First time contributor here, still learning the ropes. We're cross-compiling python in an environment where we set up CPPFLAGS, LDFLAGS, etc. to point directly to the locations where we have built Python's dependencies. For example, we will typically build Python in an environment that includes: CPPFLAGS=\ -isystem /path/to/ncurses/build/include \ -isystem /path/to/libffi/build/include \ -isystem /path/to/zlib/build/include \ -isystem /path/to/openssl/build/include \ -isystem /path/to/readline/build/include LDFLAGS=\ -L/path/to/ncurses/build/lib \ -L/path/to/libffi/build/lib \ -L/path/to/zlib/build/lib \ -L/path/to/openssl/build/lib \ -L/path/to/ciscossl-fom/build/lib \ -L/path/to/readline/build/lib setup.py already picks up our -L options from LDFLAGS and propagates them into the build commands, but the -isystem options from CPPFLAGS are currently ignored. I will post a PR that teaches setup.py to handle -isystem options in CPPFLAGS the same way it currently handles -I options. ---------- components: Cross-Build messages: 349054 nosy: Alex.Willmer, jherland priority: normal severity: normal status: open title: Need setup.py to pick up -isystem flags from CPPFLAGS type: enhancement versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 11:15:28 2019 From: report at bugs.python.org (Johan Herland) Date: Mon, 05 Aug 2019 15:15:28 +0000 Subject: [issue37763] Need setup.py to pick up -isystem flags from CPPFLAGS In-Reply-To: <1565017805.25.0.745177625686.issue37763@roundup.psfhosted.org> Message-ID: <1565018128.49.0.838851913093.issue37763@roundup.psfhosted.org> Change by Johan Herland : ---------- keywords: +patch pull_requests: +14874 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15136 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 12:23:23 2019 From: report at bugs.python.org (My Tran) Date: Mon, 05 Aug 2019 16:23:23 +0000 Subject: [issue37764] email.Message.as_string infinite loop Message-ID: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> New submission from My Tran : The following will hang the system until it runs out of memory. import email import email.policy text = """From: user at host.com To: user at host.com Bad-Header: =?us-ascii?Q?LCSwrV11+IB0rSbSker+M9vWR7wEDSuGqmHD89Gt=ea0nJFSaiz4vX3XMJPT4vrE?= =?us-ascii?Q?xGUZeOnp0o22pLBB7CYLH74Js=wOlK6Tfru2U47qR?= =?us-ascii?Q?72OfyEY2p2=2FrA9xNFyvH+fBTCmazxwzF8nGkK6D?= Hello! """ eml = email.message_from_string(text, policy=email.policy.SMTPUTF8) eml.as_string() ---------- components: email messages: 349055 nosy: barry, mytran, r.david.murray priority: normal severity: normal status: open title: email.Message.as_string infinite loop versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 12:30:21 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 05 Aug 2019 16:30:21 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565022621.87.0.815584466874.issue37764@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +maxking _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 12:31:07 2019 From: report at bugs.python.org (My Tran) Date: Mon, 05 Aug 2019 16:31:07 +0000 Subject: =?utf-8?q?=5Bissue37722=5D_imaplib_crashes_when_trying_to_read_a_letter_f?= =?utf-8?b?cm9tIGFuIGltYXAgc2VydmVyIGltYXBzLtC/0L7Rh9GC0LAu0YDRg9GB?= Message-ID: <1565022667.91.0.294983292796.issue37722@roundup.psfhosted.org> Change by My Tran : ---------- components: +email -Library (Lib) nosy: +barry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 12:49:19 2019 From: report at bugs.python.org (Ned Deily) Date: Mon, 05 Aug 2019 16:49:19 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565023759.27.0.443175789956.issue32912@roundup.psfhosted.org> Change by Ned Deily : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 12:54:08 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 05 Aug 2019 16:54:08 +0000 Subject: [issue37706] IDLE: fix sidebar click-drag bug and macOS test failures In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1565024048.1.0.277102559172.issue37706@roundup.psfhosted.org> Steve Dower added the comment: All I can add is these are the steps: https://github.com/python/cpython/blob/master/.azure-pipelines/macos-steps.yml The Linux steps use xvfb, but the macOS steps do not. And we don't do anything at all to install Tcl/Tk on the build agent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 13:11:32 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 05 Aug 2019 17:11:32 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1565025092.72.0.562033569699.issue37757@roundup.psfhosted.org> Barry A. Warsaw added the comment: I know the PEP defines TargetScopeError as a subclass of SyntaxError, but it doesn't really explain why a subclass is necessary. I think seeing "TargetScopeError" will be a head scratcher. Why not just SyntaxError without introducing a new exception? ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 13:11:53 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 05 Aug 2019 17:11:53 +0000 Subject: [issue35855] IDLE squeezer: improve unsqueezing and autosqueeze default In-Reply-To: <1548818070.19.0.784051079348.issue35855@roundup.psfhosted.org> Message-ID: <1565025113.4.0.107567841337.issue35855@roundup.psfhosted.org> Terry J. Reedy added the comment: A4: Autosqueeze long lines output in chunks. tensorflow.keras appears to do this. See #37762. Easy reproducer: for i in range(10000): print('%6s--------------------------------------------' % i, end='') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 13:21:22 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 05 Aug 2019 17:21:22 +0000 Subject: [issue37762] IDLE very slow due a super long line output in chunks In-Reply-To: <1565014260.07.0.714424226111.issue37762@roundup.psfhosted.org> Message-ID: <1565025682.03.0.0898095209091.issue37762@roundup.psfhosted.org> Terry J. Reedy added the comment: One may copy and paste small chunks of code and output into a message. By 'demo script', I presume you mean the following. import tensorflow as tf mnist = tf.keras.datasets.mnist (x_train, y_train),(x_test, y_test) = mnist.load_data() x_train, x_test = x_train / 255.0, x_test / 255.0 model = tf.keras.models.Sequential([ tf.keras.layers.Flatten(input_shape=(28, 28)), tf.keras.layers.Dense(512, activation=tf.nn.relu), tf.keras.layers.Dropout(0.2), tf.keras.layers.Dense(10, activation=tf.nn.softmax) ]) model.compile(optimizer='adam', loss='sparse_categorical_crossentropy', metrics=['accuracy']) model.fit(x_train, y_train, epochs=5) model.evaluate(x_test, y_test) The boxes represent characters that cannot be displayed in the tk Text widget with the current font. They represent whatever is printed in the standard shell, which you call 'normal', which implies that they are not control chars. Since the length of the box run is 1 less than the length of the visible data, my guess is that the intended format is alternating lines something like 9696/60000............................................ acc: 0.8691 ================================================================== except that the line separators are some non-ascii char. (Note that the sequence of [] substitutes in one less than the sequence of printable ascii, which would make it impossible to set the shell width so that wrapped chunks line up.) The problem is the absence of '\n' newlines, which I consider a bug in keras. The result is one line that grows in chunks to some humongous length. This is eventually deadly to tk Text widgets. The symptom is that chunks are added quickly at first, then more slowly, then to a crawl, and maybe a stop. Here is a short test. from __future__ import print_function # To run with 2.7. for i in range(100000): print('%6s--------------------------------------------' % i, end='') On my Win10 machine with 3.8.0b3 and tk 8.6.9 (see Help => About IDLE for the latter), slow down is evident after 10000 chars (200 chunks) and crawling by 40000 chars. It might be worse on Linux and Mac. I added a note about auto-squeezing the long lines in chunks case to #35855. I expect to close this as 3rd party, or as a duplicate of #1442493. ---------- title: IDLE very slow due to special characters -> IDLE very slow due a super long line output in chunks _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 13:25:49 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 05 Aug 2019 17:25:49 +0000 Subject: [issue37741] importlib.metadata docs not showing up in the module index In-Reply-To: <1564685225.86.0.948746560612.issue37741@roundup.psfhosted.org> Message-ID: <1565025949.31.0.993881870813.issue37741@roundup.psfhosted.org> Barry A. Warsaw added the comment: There's an importlib.metadata.rst file which describes how to use the API, but that doesn't appear to be linked from either the main library ToC or the importlib documentation itself. I'll see if I can put together a PR to fix this. ---------- assignee: docs at python -> barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 14:03:28 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 05 Aug 2019 18:03:28 +0000 Subject: [issue37765] Include keywords in autocomplete list for IDLE Message-ID: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org> New submission from Karthikeyan Singaravelan : Currently, the basic repl for python provides keywords as part of autocompletion but IDLE doesn't provide them. I was trying to build an async repl on top of IDLE to support top level await statements as part of IDLE since "python -m asyncio" doesn't provide a good repl and found during usage keywords like async/await being part of autocomplete to provide a good experience like the basic repl to type faster. I couldn't find any old issues with search around why keywords were excluded so I thought of filing a new one for this suggestion. ---------- assignee: terry.reedy components: IDLE messages: 349061 nosy: terry.reedy, xtreak priority: normal severity: normal status: open title: Include keywords in autocomplete list for IDLE type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 14:03:48 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 05 Aug 2019 18:03:48 +0000 Subject: [issue37765] Include keywords in autocomplete list for IDLE In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org> Message-ID: <1565028228.78.0.527973366429.issue37765@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 14:21:33 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 05 Aug 2019 18:21:33 +0000 Subject: [issue37741] importlib.metadata docs not showing up in the module index In-Reply-To: <1564685225.86.0.948746560612.issue37741@roundup.psfhosted.org> Message-ID: <1565029293.5.0.199577674352.issue37741@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Including a module directive with synopsis as below in importlib.metadata.rst seems to fix this. It would also be good to include a link to source code from the importlib.metadata docs page since it's written in Python. .. module:: importlib.metadata :synopsis: The implementation of the importlib metadata. **Source code:** :source:`Lib/importlib/metadata/__init__.py` ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 14:25:39 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 05 Aug 2019 18:25:39 +0000 Subject: [issue37741] importlib.metadata docs not showing up in the module index In-Reply-To: <1564685225.86.0.948746560612.issue37741@roundup.psfhosted.org> Message-ID: <1565029539.88.0.585083018564.issue37741@roundup.psfhosted.org> Barry A. Warsaw added the comment: @jaraco - Why is the code in `Lib/importlib/metadata/__init__.py` instead of `Lib/importlib/metadata.py`? Is that to make it easier to port between CPython stdlib and the standalone version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 14:29:29 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 18:29:29 +0000 Subject: [issue37765] Include keywords in autocomplete list for IDLE In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org> Message-ID: <1565029769.16.0.27883478832.issue37765@roundup.psfhosted.org> Tal Einat added the comment: The global completion list (i.e. when not completing a file name or object attribute) is already full of all the built-ins, imported modules and variables. So IMO we'd need a good reason to add yet more options into the completions list. Personally, I don't think that adding all of the keywords to that list would be helpful: They are all short words and most of them must be memorized anyways to work with Python. For instance, I don't recall this being brought up by those who often teach newcomers with IDLE, such as Raymond Hettinger, when discussing what's missing in IDLE. I'd be happy to get more input from them on this. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 14:30:19 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 18:30:19 +0000 Subject: [issue37765] Include keywords in autocomplete list for IDLE In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org> Message-ID: <1565029819.59.0.045516459155.issue37765@roundup.psfhosted.org> Tal Einat added the comment: To be clear, I'm currently -1 on this suggestion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 15:55:28 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 19:55:28 +0000 Subject: [issue35855] IDLE squeezer: improve unsqueezing and autosqueeze default In-Reply-To: <1548818070.19.0.784051079348.issue35855@roundup.psfhosted.org> Message-ID: <1565034928.31.0.949986960225.issue35855@roundup.psfhosted.org> Tal Einat added the comment: Regarding help(), there's actually a comment in IDLE's code by KBK that it should be opened in a reader (this was before TextViewer was added). IMO that's a much better approach for long help() outputs, and is simple to implement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 16:16:06 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 05 Aug 2019 20:16:06 +0000 Subject: [issue37765] IDLE: Include keywords in __main__ autocomplete list In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org> Message-ID: <1565036166.88.0.535707919401.issue37765@roundup.psfhosted.org> Terry J. Reedy added the comment: If keywords are included when the REPL has tab completions (which Windows doesn't), then it is plausible that IDLE should. It could be considered part of 'Shell should (mostly) imitate REPL'. But I can see Tal's point, though the relative expansion is pretty small. And there is nothing on the master completions issue #27609 where I collected known not-yet-rejected suggestions and ideas. The implementation is trivial. Add two new lines to autocomplete.py. So you can easily patch a private copy. I am preparing a minimal PR. import keyword # add ... def fetch_completions(self, what, mode): ... bigl = eval("dir()", namespace) bigl.extend(keyword.kwlist) # add bigl.sort() True, False, and None are also in builtins, so cannot serve as a test. --- A separate idea: annotate completion list, at least as an option, with 'keyword' or class, possibly prefixed with 'built-in', so 'built-in function', 'function', and so on. ---------- nosy: -rhettinger stage: -> test needed title: Include keywords in autocomplete list for IDLE -> IDLE: Include keywords in __main__ autocomplete list versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 16:24:22 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 05 Aug 2019 20:24:22 +0000 Subject: [issue37765] IDLE: Include keywords in __main__ autocomplete list In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org> Message-ID: <1565036662.54.0.87726521868.issue37765@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- keywords: +patch pull_requests: +14876 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/15138 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 16:33:26 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 05 Aug 2019 20:33:26 +0000 Subject: [issue37759] Polish whatsnew for 3.8 In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org> Message-ID: <1565037206.2.0.950224789921.issue37759@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 4f9ffc9d1a6a293563deaaaaf4a13331302219b4 by Raymond Hettinger in branch 'master': bpo-37759: First round of major edits to Whatsnew 3.8 (GH-15127) https://github.com/python/cpython/commit/4f9ffc9d1a6a293563deaaaaf4a13331302219b4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 16:33:38 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 05 Aug 2019 20:33:38 +0000 Subject: [issue37759] Polish whatsnew for 3.8 In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org> Message-ID: <1565037218.21.0.429177825647.issue37759@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14877 pull_request: https://github.com/python/cpython/pull/15139 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 16:34:53 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 05 Aug 2019 20:34:53 +0000 Subject: [issue37766] IDLE autocomplete: revise fetch_completions, add htest Message-ID: <1565037293.97.0.42173755359.issue37766@roundup.psfhosted.org> New submission from Terry J. Reedy : #36419 did not cover fetch_ completions. Most of the remaining 7% of autocomplete not covered by tests is in that function. I want to rename smalll to small and bigl to big (and in test file); they are awkward to read and write. I may want to revise otherwise to aid testing. The test line referencing #36405 fails when run in autocomplete itself. I need to refresh myself as to why I added it and revise or delete. Some of the test_fetch_completion needs revision, and it should be split before being augmented. An htest would make manual testing of intended behavior changes easier. ---------- assignee: terry.reedy components: IDLE messages: 349069 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE autocomplete: revise fetch_completions, add htest type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 16:37:01 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 05 Aug 2019 20:37:01 +0000 Subject: [issue27609] IDLE completions: format, factor, and fix In-Reply-To: <1469404988.71.0.674184496094.issue27609@psf.upfronthosting.co.za> Message-ID: <1565037421.53.0.439745096262.issue27609@roundup.psfhosted.org> Terry J. Reedy added the comment: #37765 Include keywords in ''(__main__) list. ###### Annotate completion list, at least as an option, with 'keyword' or class, possibly prefixed with 'built-in', so 'built-in function', 'function', and so on. #37766 revise fetch_completions, add htest ---------- dependencies: +IDLE autocomplete: revise fetch_completions, add htest, IDLE: Include keywords in __main__ autocomplete list _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 16:40:23 2019 From: report at bugs.python.org (Christopher Caputo) Date: Mon, 05 Aug 2019 20:40:23 +0000 Subject: [issue37767] TTK Treeview alternating row color not working Message-ID: <1565037623.89.0.704768758983.issue37767@roundup.psfhosted.org> New submission from Christopher Caputo : The default installation of Python3.7 on all my Win10 machines has a ttk theme file that disables treeview alternating row colors. The specific file for me is "vistaTheme.tcl" located at "C:\Program Files\Python37\tcl\tk8.6\ttk". In the #Treeview section of the file the "ttk::style map Treeview" line needed to be changed from: ttk::style map Treeview \ -background [list disabled $colors(-frame)\ {!disabled !selected} $colors(-window) \ selected SystemHighlight] \ -foreground [list disabled $colors(-disabledfg) \ {!disabled !selected} black \ selected SystemHighlightText] Changed to: ttk::style map Treeview -background [list selected SystemHighlight] -foreground [list selected SystemHighlightText] Essentially all the "disabled" parts needed to be removed. ---------- components: Tkinter messages: 349071 nosy: Mookiefer priority: normal severity: normal status: open title: TTK Treeview alternating row color not working type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 16:52:18 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 05 Aug 2019 20:52:18 +0000 Subject: [issue35855] IDLE squeezer: improve unsqueezing and autosqueeze default In-Reply-To: <1548818070.19.0.784051079348.issue35855@roundup.psfhosted.org> Message-ID: <1565038338.46.0.221984591484.issue35855@roundup.psfhosted.org> Terry J. Reedy added the comment: I presume you are proposing to wrap the site-added help with a function that would check object outputs and put them either in the shell unsqueezed or directly into a viewer. Seems plausible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 16:56:06 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 20:56:06 +0000 Subject: [issue37768] IDLE: Show help(object) output in a text viewer Message-ID: <1565038566.59.0.841955505333.issue37768@roundup.psfhosted.org> New submission from Tal Einat : Currently, IDLE just writes the entire help message into the shell. If auto-squeezing is enabled, then long help messages are automatically squeezed, following which the help text can be viewed in a text viewer or expanded inline. This is still not great UX. I propose to simply have help(object) open a text viewer with the help text. There's actually an old (2007) comment in Lib\idlelib\pyshell.py by KBK that this should be done. See related discussion in issue #35855. ---------- assignee: taleinat components: IDLE messages: 349073 nosy: taleinat, terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE: Show help(object) output in a text viewer type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 17:00:49 2019 From: report at bugs.python.org (Zachary Ware) Date: Mon, 05 Aug 2019 21:00:49 +0000 Subject: [issue37767] TTK Treeview alternating row color not working In-Reply-To: <1565037623.89.0.704768758983.issue37767@roundup.psfhosted.org> Message-ID: <1565038849.36.0.43279735724.issue37767@roundup.psfhosted.org> Zachary Ware added the comment: That file is part of Tcl/Tk and just bundled with Python on Windows; please raise an issue on the Tk issue tracker (which appears to be here: https://core.tcl-lang.org/tk/ticket). If and when the change is released in a new version of Tcl/Tk, please feel free to open a new issue here requesting that we update to that version. ---------- nosy: +zach.ware resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 17:03:52 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 21:03:52 +0000 Subject: [issue37768] IDLE: Show help(object) output in a text viewer In-Reply-To: <1565038566.59.0.841955505333.issue37768@roundup.psfhosted.org> Message-ID: <1565039032.0.0.742752499069.issue37768@roundup.psfhosted.org> Change by Tal Einat : ---------- keywords: +patch pull_requests: +14878 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15140 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 17:04:26 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 21:04:26 +0000 Subject: [issue37768] IDLE: Show help(object) output in a text viewer In-Reply-To: <1565038566.59.0.841955505333.issue37768@roundup.psfhosted.org> Message-ID: <1565039066.49.0.279890516696.issue37768@roundup.psfhosted.org> Tal Einat added the comment: See PR GH-15140. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 17:06:54 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 21:06:54 +0000 Subject: [issue37768] IDLE: Show help(object) output in a text viewer In-Reply-To: <1565038566.59.0.841955505333.issue37768@roundup.psfhosted.org> Message-ID: <1565039214.86.0.096991381357.issue37768@roundup.psfhosted.org> Tal Einat added the comment: Raymond, I'm interested in your opinion on this. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 17:13:28 2019 From: report at bugs.python.org (Ned Deily) Date: Mon, 05 Aug 2019 21:13:28 +0000 Subject: [issue37706] IDLE: fix sidebar click-drag bug and macOS test failures In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1565039608.56.0.0720479730035.issue37706@roundup.psfhosted.org> Ned Deily added the comment: Terry, using an out-of-date version of Tcl/Tk is the least of the problems here. My point was that, the way things are now, IDLE GUI tests are not being run at all on macOS Azure CI runs regardless of the Tk version in use and, AFAIK, there is no easy way to tell that from the default output from the tests. The particular test failures reported here *do* fail when properly configured to actually run using the Apple-supplied Tk 8.5.9 (in fact, with the latest fixes to the tests, all of test_idle passes with Tk 8.5.9). And I'm guessing that most times when you or Tal or other developers are running the tests from your own local builds, you aren't aware that the GUI tests are being skipped. There is a long-standing issue with Aqua Tk on macOS that, if a process tries to call Tk to draw objects on a screen but the process is not running under a username that is logged in through the normal macOS GUI (i.e. does not have a macOS Finder window, does not have a macOS "console"), Tk will segfault crashing Python along with it, which is very bad when running tests. There have been various issues about this going back a long time (see, for example, Issue22770 but there are older ones). To avoid those segfaults, we take a conservative approach in test.support._is_gui_available() (Lib/test/support/__init__.py) which is effectively (I believe) only allows GUI tests on macOS to run if they are being run under an application bundle which effectively means the Python under test must be a framework build (./configure ... --enable-framework=... ...). I believe that test is overly stringent but we haven't up to now found a reliable way to test and prevent the segfaults without depending on the framework approach. So (1) if you don't build Python with an --enable-framework= option, Tk and IDLE GUI tests are not going to be run. (2) If the GUI tests are skipped, there is no indication of this in the default log output. You only see this if you run, for example, with the regrtest -v (verbose) option: $ ./python.exe -m test -uall -j2 test_idle Run tests in parallel using 2 child processes 0:00:01 load avg: 2.56 [1/1] test_idle passed == Tests result: SUCCESS == 1 test OK. Total duration: 1 sec 753 ms Tests result: SUCCESS $ ./python.exe -m test -v -uall -j2 test_idle [...] Run tests in parallel using 2 child processes 0:00:01 load avg: 2.22 [1/1] test_idle passed skipped 'cannot run without OS X gui process' skipped 'cannot run without OS X gui process' skipped 'cannot run without OS X gui process' test_geticonname (idlelib.idle_test.test_browser.ChildBrowserTreeItemTest) ... ok test_getsublist (idlelib.idle_test.test_browser.ChildBrowserTreeItemTest) ... ok test_gettext (idlelib.idle_test.test_browser.ChildBrowserTreeItemTest) ... ok test_init (idlelib.idle_test.test_browser.ChildBrowserTreeItemTest) ... ok test_isexpandable (idlelib.idle_test.test_browser.ChildBrowserTreeItemTest) ... ok test_ondoubleclick (idlelib.idle_test.test_browser.ChildBrowserTreeItemTest) ... ok skipped 'cannot run without OS X gui process' [...] skipped 'cannot run without OS X gui process' idlelib.idle_test.test_textview (unittest.loader.ModuleSkipped) ... skipped 'cannot run without OS X gui process' idlelib.idle_test.test_tooltip (unittest.loader.ModuleSkipped) ... skipped 'cannot run without OS X gui process' idlelib.idle_test.test_tree (unittest.loader.ModuleSkipped) ... skipped 'cannot run without OS X gui process' idlelib.idle_test.test_undo (unittest.loader.ModuleSkipped) ... skipped 'cannot run without OS X gui process' test_run_show (idlelib.idle_test.test_warning.RunWarnTest) ... ok test_showwarnings (idlelib.idle_test.test_warning.RunWarnTest) ... ok test_idle_formatter (idlelib.idle_test.test_warning.ShellWarnTest) ... ok test_shell_show (idlelib.idle_test.test_warning.ShellWarnTest) ... ok test_showwarnings (idlelib.idle_test.test_warning.ShellWarnTest) ... ok skipped 'cannot run without OS X gui process' test_init (idlelib.idle_test.test_window.WindowListTest) ... ok skipped 'cannot run without OS X gui process' ---------------------------------------------------------------------- Ran 257 tests in 1.001s OK (skipped=70) == Tests result: SUCCESS == 1 test OK. Total duration: 1 sec 836 ms Tests result: SUCCESS So there is a false sense of security that tests are being run when they aren't and those skipped GUI test might be failing if they were actually run as was the case in this issue. Possible followup actions: 1. Have test_idle (and test_ttk_guionly?) issue a warning message by default if GUI tests are being skipped. 2. Investigate if it is practical to run GUI tests under Azure CI (I'm guessing it is not) or one of the other CI runners we use (Appveyor maybe?). (Note I personally will not have time to look into this until at least the Sep dev sprint so it would be good for someone else to look into it). That would also require changing the CI to make and test framework builds. 3. It *should* be possible to run GUI tests on a macOS buildbot where the console is logged into the buildbot user. That will also take some investigation and reconfiguration as a framework build. 4. Find an easier way to run macOS tests with an up-to-date Tk. I have plans to provide something in the near future. 5. It may be possible to loosen the test for GUI environment so that a framework build is not necessary but having a logged-in "console" user would need to happen anyway so that's much less important than the other items. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 17:27:29 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 05 Aug 2019 21:27:29 +0000 Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys In-Reply-To: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za> Message-ID: <1565040449.41.0.0974785326893.issue21261@roundup.psfhosted.org> Tal Einat added the comment: I had no idea that this was desired... I had this working in a old version of autocomplete back before 2010! I'm not sure whether I'll be able to find it though. I can't understand why Louie's PR was closed, it seemed to be going in the right direction... Any explanation? ---------- nosy: +taleinat versions: +Python 3.8, Python 3.9 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 18:02:48 2019 From: report at bugs.python.org (Jonas Binding) Date: Mon, 05 Aug 2019 22:02:48 +0000 Subject: [issue37769] Windows Store installer should warn user about MAX_PATH Message-ID: <1565042568.26.0.835015396911.issue37769@roundup.psfhosted.org> New submission from Jonas Binding : The "Windows Store" installer for Python has a seemingly low entry barrier, causing people to install without reading something like https://docs.python.org/3.7/using/windows.html. However, due to the really long path it uses for Python (e.g. C:\Users\USERNAME\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\), the chances of running into issues with paths longer than 260 characters are really high. For example installing pytorch already fails due to this limitation, see https://github.com/pytorch/pytorch/issues/23823 and https://www.reddit.com/r/pytorch/comments/c6cllq/issue_installing_pytorch/ Therefore, the Windows Store installer should offer to change the registry key to enable longer paths, or at least show a message to this effect. ---------- components: Windows messages: 349079 nosy: Jonas Binding, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows Store installer should warn user about MAX_PATH type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 18:09:50 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 05 Aug 2019 22:09:50 +0000 Subject: [issue37706] IDLE: fix sidebar click-drag bug and macOS test failures In-Reply-To: <1564411299.35.0.364998769852.issue37706@roundup.psfhosted.org> Message-ID: <1565042990.77.0.890745697071.issue37706@roundup.psfhosted.org> Terry J. Reedy added the comment: I remembered this morning that we need to check test_tkk_guionly or (easier, but less obviously also all gui) test_tk either in test suite output, or run by itself with python -m test.test_tk # or test -ugui test_tk because idle it has non-gui tests that always run. From a random Azure Mac output: test_ttk_guionly skipped -- cannot run without OS X gui process whereas Azure Ubuntu gives [201/419] test_ttk_guionly passed and ditto for test_tk. Also, "test_tix test_tk test_ttk_guionly" under 'tests skipped'. The skips for the only current Mac buildbot I found, https://buildbot.python.org/all/#/workers/20, Matt Billenstein High Sierra 10.13.6, also include "test_tix test_tk test_ttk_guionly" Perhaps you can ask him if his machine is suitable for adding gui tests and offer to help. Tal, when you can build on Mac, are you making framework builds? Does test_tk run? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 18:19:00 2019 From: report at bugs.python.org (Christian Berger) Date: Mon, 05 Aug 2019 22:19:00 +0000 Subject: [issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t In-Reply-To: <1561563167.55.0.111630694926.issue37415@roundup.psfhosted.org> Message-ID: <1565043540.47.0.470241605462.issue37415@roundup.psfhosted.org> Christian Berger added the comment: I have the same problem on RH6 with icc 2019.4 and Python 3.6.9. Do you want a new bug for that? Changing Include/pyatomic.h to use _Atomic as suggested by Victor in msg346785 leads to the error that _Atomic was undefined. ---------- nosy: +cberger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 18:22:17 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 05 Aug 2019 22:22:17 +0000 Subject: [issue37759] Polish whatsnew for 3.8 In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org> Message-ID: <1565043737.76.0.875963729251.issue37759@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 26f91db5ba487033994b396011518cfc80bf8401 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-37759: First round of major edits to Whatsnew 3.8 (GH-15127) (GH-15139) https://github.com/python/cpython/commit/26f91db5ba487033994b396011518cfc80bf8401 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 18:24:23 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 05 Aug 2019 22:24:23 +0000 Subject: [issue37769] Windows Store installer should warn user about MAX_PATH In-Reply-To: <1565042568.26.0.835015396911.issue37769@roundup.psfhosted.org> Message-ID: <1565043863.47.0.195554183581.issue37769@roundup.psfhosted.org> Steve Dower added the comment: Short of adding a popup into Python itself the first time you run it (and would that include if you run "pip" first?), we don't have any ability to extend the installer. We could reduce the "local-packages/Python37/site-packages" part of the path by implementing an alternative way (in both Python and pip, presumably) to specify the user's site packages. Right now, the best I can do is reduce "local-packages" down to a single character (in PC/python_uwp.cpp ) - the rest is forcibly added by the shared part of the runtime. Since pip is likely to be the first place users hit this, it might be easiest to start by adding a more descriptive error message. Copying from the other bug: pip3 install https://download.pytorch.org/whl/cpu/torch-1.1.0-cp37-cp37m-win_amd64.whl fails with an error message: ERROR: Could not install packages due to an EnvironmentError: [Errno 2] No such file or directory: 'C:\\Users\\[username]\\AppData\\Local\\Packages\\PythonSoftwareFoundation.Python.3.7_qbz5n2kfra8p0\\LocalCache\\local-packages\\Python37\\site-packages\\caffe2\\python\\serialized_test\\data\\operator_test\\collect_and_distribute_fpn_rpn_proposals_op_test.test_collect_and_dist.zip' First it seems the error is being raised incorrectly - winerror 2 is for file not found, but it's being passed as errno 2. But otherwise it should be possible to detect this case, see that the path is too long on Windows and point users at https://docs.python.org/3/using/windows.html#removing-the-max-path-limitation ---------- nosy: +Marcus.Smith, dstufft, ncoghlan, pradyunsg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 18:32:34 2019 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 05 Aug 2019 22:32:34 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1565044354.39.0.345165770198.issue37757@roundup.psfhosted.org> Guido van Rossum added the comment: [Barry] > I know the PEP defines TargetScopeError as a subclass of SyntaxError, but it doesn't really explain why a subclass is necessary. I think seeing "TargetScopeError" will be a head scratcher. Why not just SyntaxError without introducing a new exception? Hm, that's not a bad point. We report all sorts of things found by the bytecode compiler as SyntaxError. OTOH This would require a PEP change, formal review, etc. (IMO much more so than adding the new edge case that Nick and Damien discovered.) Maybe the best way of doing this would be to implement TargetScopeError now, then start the debate about killing it, and try to get that in before beta4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 18:40:03 2019 From: report at bugs.python.org (Jason Curtis) Date: Mon, 05 Aug 2019 22:40:03 +0000 Subject: [issue37770] reversed class should implement __reversed__ Message-ID: <1565044803.77.0.346292887054.issue37770@roundup.psfhosted.org> New submission from Jason Curtis : I've just been trying to implement some logic which potentially involves reversing things back to their initial orders, and it'd be nice to just be able to call reversed() on something that has already been reversed. >>> reversed(reversed([1,2,3,4])) TypeError: 'list_reverseiterator' object is not reversible Seems like this should be trivial to implement by just returning the initial iterator. Happy to post a pull request if it would be considered. ---------- components: Library (Lib) messages: 349085 nosy: jason.curtis priority: normal severity: normal status: open title: reversed class should implement __reversed__ type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 18:44:32 2019 From: report at bugs.python.org (Eryk Sun) Date: Mon, 05 Aug 2019 22:44:32 +0000 Subject: [issue37769] Windows Store installer should warn user about MAX_PATH In-Reply-To: <1565042568.26.0.835015396911.issue37769@roundup.psfhosted.org> Message-ID: <1565045072.24.0.57198748091.issue37769@roundup.psfhosted.org> Eryk Sun added the comment: > First it seems the error is being raised incorrectly - winerror 2 is > for file not found, but it's being passed as errno 2. I think this only happens with open(). The _io module could use the CRT's _doserrno value to call PyErr_SetExcFromWindowsErrWithFilenameObject. We can rely on _doserrno if _wopen fails. Otherwise this is the expected mapping from Windows ERROR_PATH_NOT_FOUND (3) or ERROR_FILENAME_EXCED_RANGE (206) to POSIX ENOENT (2). The Windows error in the case of path that's too long is not ERROR_FILE_NOT_FOUND (2). ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 18:48:55 2019 From: report at bugs.python.org (Eryk Sun) Date: Mon, 05 Aug 2019 22:48:55 +0000 Subject: [issue37769] Windows Store installer should warn user about MAX_PATH In-Reply-To: <1565042568.26.0.835015396911.issue37769@roundup.psfhosted.org> Message-ID: <1565045335.06.0.340970247104.issue37769@roundup.psfhosted.org> Eryk Sun added the comment: > I think this only happens with open(). Well, and everything else that calls a CRT function and relies on errno, such as C read() and write(). Though we'd have to look through on a case-by-case basis to ensure that _doserrno is valid in each case, i.e. that errno was set based on a Windows error code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 18:52:16 2019 From: report at bugs.python.org (Jason Curtis) Date: Mon, 05 Aug 2019 22:52:16 +0000 Subject: [issue37770] reversed class should implement __reversed__ In-Reply-To: <1565044803.77.0.346292887054.issue37770@roundup.psfhosted.org> Message-ID: <1565045536.85.0.984276486285.issue37770@roundup.psfhosted.org> Jason Curtis added the comment: Ok, not so sure about the PR now; I dug around and realized this is a C implementation and my C is likely not strong enough! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 18:54:43 2019 From: report at bugs.python.org (Jason Curtis) Date: Mon, 05 Aug 2019 22:54:43 +0000 Subject: [issue37770] implement __reversed__ on reversed types In-Reply-To: <1565044803.77.0.346292887054.issue37770@roundup.psfhosted.org> Message-ID: <1565045683.26.0.490323154018.issue37770@roundup.psfhosted.org> Change by Jason Curtis : ---------- title: reversed class should implement __reversed__ -> implement __reversed__ on reversed types _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 19:03:51 2019 From: report at bugs.python.org (Ulf Magnusson) Date: Mon, 05 Aug 2019 23:03:51 +0000 Subject: [issue2889] curses for windows (alternative patch) In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za> Message-ID: <1565046231.51.0.970622017056.issue2889@roundup.psfhosted.org> Ulf Magnusson added the comment: Just as an FYI, there is a repository for building curses wheels for Windows at https://github.com/zephyrproject-rtos/windows-curses, based on patches from here and Gohlke's work. Building wheels is less straightforward than it used to be, e.g. due to term.h disappearing from PDCurses. We also make wheels available on PyPI. ---------- nosy: +ulfalizer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 19:20:31 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 05 Aug 2019 23:20:31 +0000 Subject: [issue37741] importlib.metadata docs not showing up in the module index In-Reply-To: <1564685225.86.0.948746560612.issue37741@roundup.psfhosted.org> Message-ID: <1565047231.58.0.761172405692.issue37741@roundup.psfhosted.org> Jason R. Coombs added the comment: > Why is the code in `Lib/importlib/metadata/__init__.py` Mainly because originally, the code was in multiple modules. I'm happy for it to move into a single file module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 19:34:25 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 05 Aug 2019 23:34:25 +0000 Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys In-Reply-To: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za> Message-ID: <1565048065.14.0.84102673838.issue21261@roundup.psfhosted.org> Terry J. Reedy added the comment: The history is confusing. bpo user Louie Lu (louielu), as github user 'noname louisom', open PR 1511 for this existing issue on 2017 May 9. On May 12, he opened #30348 and PR 1512 with the tests for fetch_completions and get_entity that were part of PR 1511. (This was a needed separation.) By June, he had switched to a new github name 'Louie Lu mlouielu'. On June 12, he opened #30632 and PR 2124, which duplicated #30348 and PR 1512 (which partly duplicated PR 1511). On June 15, he closed PR 1511 to 'migrate' it to pr 2209. But the latter only included the tests also in PR 1512, which it replaced on #30348, and PR 2124. He also closed #1512. Loiue moved on to other projects in Fall, 2017. After revisions, I merged PR 2209 for #30348 last March. I followed up with #36419, PR 15121, now merged. I just opened #37766 to finish preparing autocomplete for new additions such as this. I was thinking of this issue when I included adding an htest. (Note: #27609 is the master issue for completions.) Notes for migrating the dict keys code: 1. In PR 15121, I shrank mode names to ATTRS and FILES. The new mode name should be KEYS, or maybe SKEYS (for string keys). Other refactors should not affect KEYS too much. 2. I intend to change 'smalll' and 'bigl' to 'small' and 'big' and might make other changes to fetch_completions. 3. I intend to split test_fetch_completions into separate methods for each mode. The new KEYS tests should be a separate method 'test_fetch_keys'. The questions of function calls in the entity expression is more nuanced than I know when I wrote msg293520. For force-open-completions, control-space, function calls are allowed. But I do not think that this affects the new mode. ---------- assignee: -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 20:33:42 2019 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 06 Aug 2019 00:33:42 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1565051622.43.0.253195209759.issue37757@roundup.psfhosted.org> Nick Coghlan added the comment: I believe our main motivation for separating it out was the fact that even though TargetScopeError is a compile-time error, the affected code is syntactically fine - there are just issues with unambiguously inferring the intended read/write location for the affected target names. (Subclassing SyntaxError is then a pragmatic concession to the fact that "SyntaxError" also de facto means "CompilationError") Searching for "Python TargetScopeError" will also get folks to relevant information far more quickly than searching for "Python SyntaxError" will. Pre-seeding Stack Overflow with an answer to "What does TargetScopeError mean in Python?" would probably be a good idea though (similar to what I did for https://stackoverflow.com/questions/25445439/what-does-syntaxerror-missing-parentheses-in-call-to-print-mean-in-python ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 21:20:31 2019 From: report at bugs.python.org (GeeVye) Date: Tue, 06 Aug 2019 01:20:31 +0000 Subject: [issue37771] No equivalent of `inspect.getcoroutinestate` for PyAsyncGenASend instances Message-ID: <1565054430.97.0.58176402921.issue37771@roundup.psfhosted.org> New submission from GeeVye : In PEP 525, async generators were introduced. They use `.asend()` and `.athrow()` methods that return a "coroutine-like" object - specifically, a PyAsyncGenASend and PyAsyncGenAThrow respectively. While these "coroutine-like" object implement `.send()`, `.throw()`, and `.close()`, they don't provide any attributes like normal coroutine objects do such as `cr_running` or `cr_await`. When I use `inspect.getcoroutinestate()`, it raises an AttributeError on how there isn't a `cr_running` attribute / flag. There is a workaround I use which is to wrap it with another coroutine as below: >>> async def async_generator(): ... yield ... >>> async def wrap_coro(coro): ... return await coro >>> agen = async_generator() >>> asend = wrap_coro(agen.asend(None)) This seems like something that should be changed to make it more inline with normal coroutines / awaitables. ---------- components: Demos and Tools messages: 349093 nosy: GeeVye priority: normal severity: normal status: open title: No equivalent of `inspect.getcoroutinestate` for PyAsyncGenASend instances type: behavior versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 21:38:01 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 06 Aug 2019 01:38:01 +0000 Subject: [issue37771] No equivalent of `inspect.getcoroutinestate` for PyAsyncGenASend instances In-Reply-To: <1565054430.97.0.58176402921.issue37771@roundup.psfhosted.org> Message-ID: <1565055481.85.0.973878540463.issue37771@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 21:53:07 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 06 Aug 2019 01:53:07 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1565056387.0.0.432378673293.issue37757@roundup.psfhosted.org> Guido van Rossum added the comment: But we don't do that with any of the other (many) errors detected by later passes of the compiler. Those report dozens of SyntaxErrors, with good descriptive messages. Users can search the web for those messages too. Also, I doubt that many people will ever get a TargetScopeError. The examples are all esoteric -- yes, the compiler needs to reject them, but no, they are not things one is likely to try intentionally. (The exception may be the forbidden form you're adding, [... for ... in (i := ...)].) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 21:53:49 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 06 Aug 2019 01:53:49 +0000 Subject: [issue37770] implement __reversed__ on reversed types In-Reply-To: <1565044803.77.0.346292887054.issue37770@roundup.psfhosted.org> Message-ID: <1565056429.87.0.459310896104.issue37770@roundup.psfhosted.org> Steven D'Aprano added the comment: Both 3.7 and 3.8 are in feature-freeze, so the earliest we can get this would be 3.9. But before that, we have to decide on what reversing a reversed object means. it = reversed([1, 2, 3, 4]) next(it) list( reversed(it) ) Should that give [1, 2, 3] or [1, 2, 3, 4]? I think that either answer will annoy and surprise some people. [1, 2, 3] will surprise those who expect to get the original iterable back. [1, 2, 3, 4] will surprise those who expect reversed to operate on the current state of an iterator, not it's previous state. ---------- nosy: +steven.daprano versions: +Python 3.9 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 22:40:12 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 06 Aug 2019 02:40:12 +0000 Subject: [issue37765] IDLE: Include keywords in __main__ autocomplete list In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org> Message-ID: <1565059212.96.0.743002286103.issue37765@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Thanks Terry, I used a similar patch. My main use case was around typing where normal shell autocompletes it and was curious if it was intentional. I didn't know that windows didn't give keywords. The keywords are short and added very rarely and perhaps the bigger completion list to actual usage might be low since no one opened this issue as Tal mentioned I am open to others feedback. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 5 23:35:52 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 06 Aug 2019 03:35:52 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565062552.9.0.452778889858.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: Hello I would like to work on this issue. First time contributor here. Would putting the import _crypt statement on line 3 in crypt.py inside a try/except block and checking to see if platform is windows then give an appropriate message be a good fix? Thank you -Srinivas ---------- nosy: +shireenrao _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 00:35:37 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 06 Aug 2019 04:35:37 +0000 Subject: [issue37770] implement __reversed__ on reversed types In-Reply-To: <1565044803.77.0.346292887054.issue37770@roundup.psfhosted.org> Message-ID: <1565066137.54.0.87427545681.issue37770@roundup.psfhosted.org> Raymond Hettinger added the comment: > Happy to post a pull request if it would be considered. I don't we should do this. Mostly, it seems pointless, but it also isn't really something we would want people to be doing. > Should that give [1, 2, 3] or [1, 2, 3, 4]? I think that > either answer will annoy and surprise some people. Right. I don't think we should open this can of worms. Thank for you the suggestion, but we should decline this one unless a compelling use case arises. ---------- nosy: +rhettinger resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 00:37:43 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 06 Aug 2019 04:37:43 +0000 Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys In-Reply-To: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za> Message-ID: <1565066263.12.0.859182220597.issue21261@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks for going through the history of this issue. It was surprisingly convoluted. I still hope this feature comes to fruition. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 01:06:49 2019 From: report at bugs.python.org (Inada Naoki) Date: Tue, 06 Aug 2019 05:06:49 +0000 Subject: [issue34488] improve performance of BytesIO.writelines() by avoiding creation of unused PyLongs In-Reply-To: <1535133350.73.0.56676864532.issue34488@psf.upfronthosting.co.za> Message-ID: <1565068009.06.0.682436342761.issue34488@roundup.psfhosted.org> Change by Inada Naoki : ---------- components: +IO -Extension Modules versions: +Python 3.9 -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 01:46:15 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 06 Aug 2019 05:46:15 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1565070375.01.0.970607983819.issue37757@roundup.psfhosted.org> Serhiy Storchaka added the comment: > We report all sorts of things found by the bytecode compiler as SyntaxError. Except of these which are reported with IndentationError or its subclass TabError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 02:57:30 2019 From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=) Date: Tue, 06 Aug 2019 06:57:30 +0000 Subject: [issue37772] zipfile.Path.iterdir() outputs sub directories many times or not at all Message-ID: <1565074650.65.0.762547380277.issue37772@roundup.psfhosted.org> New submission from J?rn Heissler : Hello, #!/usr/bin/python3.8 from zipfile import ZipFile, Path import io def recurse_print(parent): for child in parent.iterdir(): if child.is_file(): print(child, child.read_text()) if child.is_dir(): recurse_print(child) data = io.BytesIO() zf = ZipFile(data, "w") zf.writestr("a.txt", "content of a") zf.writestr("b/c.txt", "content of c") zf.writestr("b/d/e.txt", "content of e") zf.writestr("b/f.txt", "content of f") zf.filename = "abcde.zip" root = Path(zf) recurse_print(root) Expected result: abcde.zip/a.txt content of a abcde.zip/b/c.txt content of c abcde.zip/b/f.txt content of f abcde.zip/b/d/e.txt content of e Actual result: abcde.zip/a.txt content of a abcde.zip/b/c.txt content of c abcde.zip/b/f.txt content of f abcde.zip/b/d/e.txt content of e abcde.zip/b/c.txt content of c abcde.zip/b/f.txt content of f abcde.zip/b/d/e.txt content of e Path._add_implied_dirs adds the sub directory "b/" twice: once for each direct child (i.e. "c.txt" and "f.txt") And similarly: data = io.BytesIO() zf = ZipFile(data, "w") zf.writestr("a.txt", "content of a") zf.writestr("b/d/e.txt", "content of e") zf.filename = "abcde.zip" root = Path(zf) recurse_print(root) Expected result: abcde.zip/a.txt content of a abcde.zip/b/d/e.txt content of e Actual result: abcde.zip/a.txt content of a Here, Path._add_implied_dirs doesn't add "b/" at all, because there are no direct childs of "b". ---------- components: Library (Lib) messages: 349101 nosy: joernheissler priority: normal severity: normal status: open title: zipfile.Path.iterdir() outputs sub directories many times or not at all type: behavior versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 04:01:26 2019 From: report at bugs.python.org (Ma Lin) Date: Tue, 06 Aug 2019 08:01:26 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in some files In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1565078486.7.0.103203559904.issue37752@roundup.psfhosted.org> Ma Lin added the comment: VC2017 optimizes multiple `unsigned char)((c) & 0xff` to a single `movzx` operation, maybe other compilers do it as well. If so, there will be no performance changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 04:08:02 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 06 Aug 2019 08:08:02 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565078882.66.0.0185930218837.issue32912@roundup.psfhosted.org> Gregory P. Smith added the comment: Can the pyc compilation step done by our normal package installers be made to treat this warning as an error so that it is forced into the package owners faces instead of overlooked because it was just something on stderr? This syntax warning is absolutely the right thing to surface for _owners/maintainers_ of a given piece of code. Their strings are wrong and their code quality will improve as a result. It isn't the right thing to surface to _users_ of someone else's problematic code. (though it does serve as a red flag proving that the owners of that code or person who pinned some dep to an old version haven't proactively tested with modern python) ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 05:35:50 2019 From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=) Date: Tue, 06 Aug 2019 09:35:50 +0000 Subject: [issue37773] ValueError: I/O operation on closed file. in ZipFile destructor Message-ID: <1565084150.95.0.74829896398.issue37773@roundup.psfhosted.org> New submission from J?rn Heissler : When running this code: from zipfile import ZipFile import io def foo(): pass data = io.BytesIO() zf = ZipFile(data, "w") I get this message: Exception ignored in: Traceback (most recent call last): File "/home/user/git/oss/cpython/Lib/zipfile.py", line 1800, in __del__ File "/home/user/git/oss/cpython/Lib/zipfile.py", line 1817, in close ValueError: I/O operation on closed file. Comment out def foo: pass, and there is no error. It looks like the bug was introduced with commit ada319bb6d0ebcc68d3e0ef2b4279ea061877ac8 (bpo-32388). ---------- messages: 349104 nosy: joernheissler, pitrou priority: normal severity: normal status: open title: ValueError: I/O operation on closed file. in ZipFile destructor type: crash versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 05:41:22 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 06 Aug 2019 09:41:22 +0000 Subject: [issue37773] ValueError: I/O operation on closed file. in ZipFile destructor In-Reply-To: <1565084150.95.0.74829896398.issue37773@roundup.psfhosted.org> Message-ID: <1565084482.34.0.487463406158.issue37773@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This looks like a regression in 3.8 so I have added 3.8 regression tag. ---------- keywords: +3.8regression nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 06:51:16 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 06 Aug 2019 10:51:16 +0000 Subject: [issue37773] ValueError: I/O operation on closed file. in ZipFile destructor In-Reply-To: <1565084150.95.0.74829896398.issue37773@roundup.psfhosted.org> Message-ID: <1565088676.2.0.0706451515959.issue37773@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 07:10:17 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 06 Aug 2019 11:10:17 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565089817.16.0.00377882298346.issue32912@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +14879 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/15142 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 07:11:14 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 06 Aug 2019 11:11:14 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565089874.15.0.981032148452.issue32912@roundup.psfhosted.org> Serhiy Storchaka added the comment: PR 15142 reverts that change for 3.8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 09:15:47 2019 From: report at bugs.python.org (Thomas Grainger) Date: Tue, 06 Aug 2019 13:15:47 +0000 Subject: [issue1967] Backport dictviews to 2.7 In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za> Message-ID: <1565097347.71.0.111321548808.issue1967@roundup.psfhosted.org> Thomas Grainger added the comment: It seems that 'viewkeys', 'viewvalues' and 'viewitems' methods were not added to types.DictProxyType, was that intentional? ---------- nosy: +graingert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 09:24:16 2019 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Aug 2019 13:24:16 +0000 Subject: [issue1967] Backport dictviews to 2.7 In-Reply-To: <1201646345.65.0.388341439945.issue1967@psf.upfronthosting.co.za> Message-ID: <1565097856.35.0.0435223532143.issue1967@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +14880 pull_request: https://github.com/python/cpython/pull/15143 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 09:40:48 2019 From: report at bugs.python.org (George Zhang) Date: Tue, 06 Aug 2019 13:40:48 +0000 Subject: [issue37771] No equivalent of `inspect.getcoroutinestate` for PyAsyncGenASend instances In-Reply-To: <1565054430.97.0.58176402921.issue37771@roundup.psfhosted.org> Message-ID: <1565098848.74.0.349864188681.issue37771@roundup.psfhosted.org> Change by George Zhang : ---------- versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 10:00:15 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Tue, 06 Aug 2019 14:00:15 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY Message-ID: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> New submission from Jeroen Demeyer : Take the LIKELY/UNLIKELY macros out of Objects/obmalloc.c (renaming them of course). Use them in a few places to micro-optimize vectorcall. ---------- components: Interpreter Core messages: 349108 nosy: Mark.Shannon, inada.naoki, jdemeyer priority: normal severity: normal status: open title: Micro-optimize vectorcall using PY_LIKELY versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 10:09:49 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 06 Aug 2019 14:09:49 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565100589.99.0.945151196979.issue37774@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 10:27:39 2019 From: report at bugs.python.org (Tal Einat) Date: Tue, 06 Aug 2019 14:27:39 +0000 Subject: [issue37762] IDLE very slow due a super long line output in chunks In-Reply-To: <1565014260.07.0.714424226111.issue37762@roundup.psfhosted.org> Message-ID: <1565101659.53.0.838132725321.issue37762@roundup.psfhosted.org> Tal Einat added the comment: IDLE in general doesn't recognize and support control characters commonly used in terminals. This is often a problem with running things that show a progress bars, which usually print "\r" to return the cursor to the beginning of the line and then overwrite the line, over and over again. Since IDLE doesn't support this properly, what you get instead is all of the progress output one after another on a single line. To make matters worse, very long lines make IDLE's shell increasingly slow, at worst becoming almost entirely unresponsive. This compounds the issue with progress bars. It would be interesting to see what Jupyter does in these cases, since apparently such examples work well in Jupyter. Perhaps we can do something similar. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 10:34:39 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Tue, 06 Aug 2019 14:34:39 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565102079.85.0.164089409409.issue37774@roundup.psfhosted.org> Change by Jeroen Demeyer : ---------- keywords: +patch pull_requests: +14881 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15144 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 10:44:44 2019 From: report at bugs.python.org (Tal Einat) Date: Tue, 06 Aug 2019 14:44:44 +0000 Subject: [issue37762] IDLE very slow due a super long line output in chunks In-Reply-To: <1565014260.07.0.714424226111.issue37762@roundup.psfhosted.org> Message-ID: <1565102684.26.0.346812588195.issue37762@roundup.psfhosted.org> Tal Einat added the comment: So, Jupyter notebook has special support for carriage-return ('\r') and backspace ('\b') characters[1]. Do we want to consider adding similar support in IDLE? [1] https://github.com/jupyter/notebook/blob/e498de6775b3de57f5ff827e562c179b17893064/notebook/static/base/js/utils.js#L479 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 11:17:06 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 06 Aug 2019 15:17:06 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565104626.51.0.845125080308.issue25172@roundup.psfhosted.org> Steve Dower added the comment: That sounds good to me, though you may want to propose the error message here first so we can get the wording right - probably not everyone will be watching github PR. It probably makes sense to raise a different error message on platforms where we do expect it to have been built - the same confusion could arise there. Some starting points (that will likely need improvement): win32: raise ImportError("The crypt module is not supported on Windows") not win32: raise ImportError("The required _crypt module was not built as part of CPython") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 12:26:42 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 06 Aug 2019 16:26:42 +0000 Subject: [issue37734] Registry keys for Windows Store package have wrong executable In-Reply-To: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org> Message-ID: <1565108802.1.0.302823757641.issue37734@roundup.psfhosted.org> Steve Dower added the comment: It looks like the best solution here may be to rename the bundled executables to "python3.8.exe" etc. rather than "python.exe". We will still keep the "python.exe" alias, and sys.executable won't change (it'll still point to the stable alias), but by having the "core" executable be named differently between Python versions it'll fix a couple of minor issues. Most importantly here, because the registry path would then point at "python3.8.exe" rather than "python.exe", it becomes more likely that the global alias will remain enabled and so launching via the registry path will work. The downside is that apps that use "$InstallPath\python.exe" rather than "$ExecutablePath" will not work. But the ExecutablePath value has been present for a while now, and PEP 514 specifies it as preferred when available, so I think that's okay. We can also include a plain "python[w].exe" in the installation, but that'll only be useful for subprocess.run("python") from the same version - it won't be executable at all from outside the app package. (None of this affects the regular installer, FWIW. That'll still be plain "python.exe".) Anyone have any thoughts or concerns? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 12:47:22 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 06 Aug 2019 16:47:22 +0000 Subject: [issue37734] Registry keys for Windows Store package have wrong executable In-Reply-To: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org> Message-ID: <1565110042.55.0.618995327568.issue37734@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch pull_requests: +14882 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15146 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 12:48:16 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 06 Aug 2019 16:48:16 +0000 Subject: [issue35982] Create unit-tests for os.renames() In-Reply-To: <1550050887.9.0.145116201828.issue35982@roundup.psfhosted.org> Message-ID: <1565110096.85.0.513666083142.issue35982@roundup.psfhosted.org> Joannah Nanjekye added the comment: @giampaolo, are you still working on these tests? If not can someone else pick this up? ---------- components: +Tests stage: -> needs patch versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 12:53:33 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 06 Aug 2019 16:53:33 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565110413.9.0.672558858157.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: What is the recommended way to check for platform in cpython? Is it using the sys module or os module? As for the error messages I couldn't think of anything better then what you suggested :). win32: raise ImportError("The crypt module is not supported on Windows") not win32: raise ImportError("The required _crypt module was not built as part of CPython") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:09:42 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 06 Aug 2019 17:09:42 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565111382.22.0.430913898014.issue25172@roundup.psfhosted.org> Steve Dower added the comment: `sys.platform` is the value that reflects how Python was compiled - `sys.platform == 'win32'` means compiled for Windows. And since this issue is related to compilation, it makes the most sense to use sys. (`os.name` is also based on compilation, but it really only reflects the POSIX implementation in use, which is why sys is better.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:12:06 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 06 Aug 2019 17:12:06 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565111526.43.0.282818446592.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: Sounds good. Can I submit my PR now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:20:56 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 06 Aug 2019 17:20:56 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565112056.21.0.596397265479.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: I forgot to ask about tests? I see there is test_crypt.py under Lib\test. Do you have any thoughts on how to test this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:23:25 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 06 Aug 2019 17:23:25 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565112205.98.0.995624795325.issue25172@roundup.psfhosted.org> Steve Dower added the comment: > Can I submit my PR now? Sure, though if others want to weigh in on wording they should feel free to do it here. > I forgot to ask about tests? I see there is test_crypt.py under Lib\test. Do you have any thoughts on how to test this? It should continue to "successfully" skip tests when _crypt isn't built. So as long as you raise ImportError, this should be fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:25:04 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 06 Aug 2019 17:25:04 +0000 Subject: [issue36225] Lingering subinterpreters should be implicitly cleared on shutdown In-Reply-To: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org> Message-ID: <1565112304.75.0.699625088034.issue36225@roundup.psfhosted.org> Joannah Nanjekye added the comment: I am investigating this but in the meantime. > It also occurs to me that we don't currently have a test case for what happens if you call Py_Finalize from a sub-interpreter rather than the main interpreter. @ncoghlan Am moving this test request in a new issue. So that this issue only focuses on fixing the lingering sub-interpreters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:38:00 2019 From: report at bugs.python.org (hai shi) Date: Tue, 06 Aug 2019 17:38:00 +0000 Subject: [issue37775] update doc of compileall Message-ID: <1565113080.48.0.890450145581.issue37775@roundup.psfhosted.org> New submission from hai shi : due to https://github.com/python/cpython/commit/a6b3ec5b6d4f6387820fccc570eea08b9615620d, we need update invalidation_mode's value from py_compile.PycInvalidationMode.TIMESTAMP to None in compile_xx function. ---------- assignee: docs at python components: Documentation messages: 349120 nosy: docs at python, shihai1991 priority: normal severity: normal status: open title: update doc of compileall versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:38:32 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 06 Aug 2019 17:38:32 +0000 Subject: [issue19982] Add a "target" parameter to runpy.run_path and runpy.run_module In-Reply-To: <1387027323.14.0.795736210788.issue19982@psf.upfronthosting.co.za> Message-ID: <1565113112.97.0.45243707831.issue19982@roundup.psfhosted.org> Joannah Nanjekye added the comment: issue 19978 also needs this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:40:23 2019 From: report at bugs.python.org (hai shi) Date: Tue, 06 Aug 2019 17:40:23 +0000 Subject: [issue37775] update doc of compileall In-Reply-To: <1565113080.48.0.890450145581.issue37775@roundup.psfhosted.org> Message-ID: <1565113223.2.0.720196792263.issue37775@roundup.psfhosted.org> Change by hai shi : ---------- keywords: +patch pull_requests: +14883 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15148 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:41:06 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 06 Aug 2019 17:41:06 +0000 Subject: [issue19978] Update multiprocessing.spawn to use runpy.run_path In-Reply-To: <1386953081.33.0.610270366508.issue19978@psf.upfronthosting.co.za> Message-ID: <1565113266.99.0.498605485801.issue19978@roundup.psfhosted.org> Joannah Nanjekye added the comment: Working on issue 19982 is important prior to this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:43:30 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 06 Aug 2019 17:43:30 +0000 Subject: [issue37776] Test Py_Finalize() from a subinterpreter Message-ID: <1565113410.42.0.547052767114.issue37776@roundup.psfhosted.org> New submission from Joannah Nanjekye : Am opening a test request from @ncoghlan from the discussing on issue 36225. There is a need to add a test that exercises what happens when Py_Finalize() is called from a sub-interpreter rather than the main interpreter. ---------- messages: 349123 nosy: eric.snow, nanjekyejoannah, ncoghlan priority: normal severity: normal status: open title: Test Py_Finalize() from a subinterpreter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:44:25 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 06 Aug 2019 17:44:25 +0000 Subject: [issue36225] Lingering subinterpreters should be implicitly cleared on shutdown In-Reply-To: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org> Message-ID: <1565113465.71.0.191525220802.issue36225@roundup.psfhosted.org> Joannah Nanjekye added the comment: The test request is moved to issue37776. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:45:05 2019 From: report at bugs.python.org (Paul Moore) Date: Tue, 06 Aug 2019 17:45:05 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565113505.51.0.113630571716.issue25172@roundup.psfhosted.org> Paul Moore added the comment: The proposed wording seems good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:46:05 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 06 Aug 2019 17:46:05 +0000 Subject: [issue37776] Test Py_Finalize() from a subinterpreter In-Reply-To: <1565113410.42.0.547052767114.issue37776@roundup.psfhosted.org> Message-ID: <1565113565.33.0.0958556441554.issue37776@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- components: +Tests stage: -> needs patch versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:48:34 2019 From: report at bugs.python.org (hai shi) Date: Tue, 06 Aug 2019 17:48:34 +0000 Subject: [issue27379] SocketType changed in Python 3 In-Reply-To: <1466738397.82.0.0999219877747.issue27379@psf.upfronthosting.co.za> Message-ID: <1565113714.43.0.954912496605.issue27379@roundup.psfhosted.org> hai shi added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:49:17 2019 From: report at bugs.python.org (hai shi) Date: Tue, 06 Aug 2019 17:49:17 +0000 Subject: [issue37583] Got a 113 error when running the test_socket In-Reply-To: <1563006871.17.0.626459715079.issue37583@roundup.psfhosted.org> Message-ID: <1565113757.64.0.567375309759.issue37583@roundup.psfhosted.org> hai shi added the comment: ping :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 13:54:30 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 06 Aug 2019 17:54:30 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565114070.46.0.103445015286.issue25172@roundup.psfhosted.org> Change by Srinivas Nyayapati : ---------- keywords: +patch pull_requests: +14884 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15149 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 14:14:01 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 06 Aug 2019 18:14:01 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565115241.09.0.614526156268.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: Sorry, I should have waited 1 day after submitting the CLA before submitting the PR. The system is waiting for my CLA to be cleared. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 15:40:05 2019 From: report at bugs.python.org (Paul Moore) Date: Tue, 06 Aug 2019 19:40:05 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565120405.27.0.46418948611.issue25172@roundup.psfhosted.org> Paul Moore added the comment: It might be worth adding a test (running only on Windows) to confirm that if you try to import crypt you get an import error with a message that includes the phrase "not supported". That will ensure that we don't get regressions here in future, while still not tying us too strictly to the exact wording. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 15:49:52 2019 From: report at bugs.python.org (Casey) Date: Tue, 06 Aug 2019 19:49:52 +0000 Subject: [issue37777] imap breaks on OpenSSL 1.1.1 when SNI is enforced Message-ID: <1565120992.49.0.0764506500298.issue37777@roundup.psfhosted.org> New submission from Casey : OpenSSL 1.1.1 is an LTS release that will see long maintenance, and Ubuntu 18.04 LTS has now upgraded from 1.1.0 to 1.1.1. However, with this upgrade, TLS 1.3 allows email clients to require an SNI for the handshake to succeed. Because the 2.7 imap module does not enforce or provide SNI to the handshake, Python 2.7 with OpenSSL 1.1.1 will break if an email client requires the SNI hostname. Relevant 2.7 file: https://github.com/python/cpython/blob/2.7/Lib/imaplib.py Right now, the only email client that enforces an SNI header to connect is GMail, and this is why no SSL or imap tests would currently fail due to this issue. This issue was addressed in Python 3.4 but not backported as far as I've been able to tell: https://github.com/python/cpython/commit/7243b574e5fc6f9ae68dc5ebd8252047b8e78e3b With a few releases still planned for Python 2.7 before EOL according to Pep 373, while this is not directly a security issue it does block the use of the latest OpenSSL package and seems like a useful inclusion to the last few releases. Happy to submit a backport PR (in progress) if that's likely. Reproduce steps here: https://github.com/CaseyFaist/reproduceSNIcase ---------- assignee: christian.heimes components: SSL messages: 349131 nosy: alex, cfactoid, christian.heimes, dstufft, janssen priority: normal severity: normal status: open title: imap breaks on OpenSSL 1.1.1 when SNI is enforced type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 16:07:14 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 06 Aug 2019 20:07:14 +0000 Subject: [issue37778] Windows Store package uses wrong icons for file association Message-ID: <1565122034.52.0.620169066443.issue37778@roundup.psfhosted.org> New submission from Steve Dower : No Logo element is specified in the FileTypeAssociation element, and so files get a different icon from the regular installer. See https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/appxmanifestschema/element-1-logo ---------- assignee: steve.dower components: Windows messages: 349132 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Windows Store package uses wrong icons for file association type: behavior versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 16:22:40 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=) Date: Tue, 06 Aug 2019 20:22:40 +0000 Subject: [issue37779] configparser: add documentation about several read() behaviour Message-ID: <1565122960.66.0.217084239893.issue37779@roundup.psfhosted.org> New submission from St?phane Blondon : The documentation is not explicit about the behaviour if several files are read by the same ConfigParser: the data are not reset between two read(). I suggest to add such information in the documentation. There is a draft: === start === When a `ConfigParser` instance make several calls of `read_file()`, `read_string()` or `read_dict()` functions, the previous data will be overriden by the new ones. Otherwise, the previous data is kept. This behaviour is equivalent to a `read()` call with several files passed to `filenames` parameter`. Example: config = configparser.ConfigParser() s = """ [spam] alpha=1 """ config.read_string(s) # dict(config["spam"]) == {'alpha': '1'} config.read_string("") # dict(config["spam"]) == {'alpha': '1'} === end === What do you think about it? I can do a PR but I wonder where is the best location in the documentation to insert it. At the end of the 'Quick start paragraph' (https://docs.python.org/3/library/configparser.html#quick-start)? Or perhaps a new paragraph after 'Fallback Values'? Other location? ---------- components: Library (Lib) messages: 349133 nosy: sblondon priority: normal severity: normal status: open title: configparser: add documentation about several read() behaviour type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 16:55:22 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 06 Aug 2019 20:55:22 +0000 Subject: [issue37778] Windows Store package uses wrong icons for file association In-Reply-To: <1565122034.52.0.620169066443.issue37778@roundup.psfhosted.org> Message-ID: <1565124922.44.0.348753234342.issue37778@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch pull_requests: +14886 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15150 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 17:03:21 2019 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 Aug 2019 21:03:21 +0000 Subject: [issue37772] zipfile.Path.iterdir() outputs sub directories many times or not at all In-Reply-To: <1565074650.65.0.762547380277.issue37772@roundup.psfhosted.org> Message-ID: <1565125401.45.0.599085963395.issue37772@roundup.psfhosted.org> Change by Brett Cannon : ---------- nosy: +jaraco _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 17:05:03 2019 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 Aug 2019 21:05:03 +0000 Subject: [issue37775] update doc of compileall In-Reply-To: <1565113080.48.0.890450145581.issue37775@roundup.psfhosted.org> Message-ID: <1565125503.94.0.0816042512334.issue37775@roundup.psfhosted.org> Change by Brett Cannon : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 17:05:52 2019 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 Aug 2019 21:05:52 +0000 Subject: [issue37444] Differing exception between builtins and importlib when importing beyond top-level package In-Reply-To: <1561749733.32.0.955430999512.issue37444@roundup.psfhosted.org> Message-ID: <1565125552.66.0.0145725806498.issue37444@roundup.psfhosted.org> Change by Brett Cannon : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 17:07:42 2019 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 Aug 2019 21:07:42 +0000 Subject: [issue37741] importlib.metadata docs not showing up in the module index In-Reply-To: <1564685225.86.0.948746560612.issue37741@roundup.psfhosted.org> Message-ID: <1565125662.44.0.867092250529.issue37741@roundup.psfhosted.org> Brett Cannon added the comment: If there's no porting benefit then let's move it to a single module instead of a package. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 17:26:53 2019 From: report at bugs.python.org (Zackery Spytz) Date: Tue, 06 Aug 2019 21:26:53 +0000 Subject: [issue2920] Patch to print symbolic value of errno in OSError.__str__() In-Reply-To: <1211228076.96.0.534347381118.issue2920@psf.upfronthosting.co.za> Message-ID: <1565126813.38.0.35009741331.issue2920@roundup.psfhosted.org> Zackery Spytz added the comment: Eryk, I'm not sure if something similar should be done for winerror. I think it's best to keep OSError_str() as simple as possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 17:49:23 2019 From: report at bugs.python.org (Casey) Date: Tue, 06 Aug 2019 21:49:23 +0000 Subject: [issue37777] imap breaks on OpenSSL 1.1.1 when SNI is enforced In-Reply-To: <1565120992.49.0.0764506500298.issue37777@roundup.psfhosted.org> Message-ID: <1565128163.43.0.677403761272.issue37777@roundup.psfhosted.org> Casey added the comment: Update: After digging further (and enabling the "Less secure app access" setting on the test Google account) it looks like Python 2.7 caps TLS at 1.2 rather than using 1.3 when OpenSSL is upgraded. This prevents breakage, and it looks like the SSLSocket class silences the handshake complaints. If this were an active branch, this could be worth revisiting - but since 2.7 is soon to be EOL and we can't reproduce the breakage, not sure it's worth it. ---------- stage: -> resolved status: open -> closed type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 18:04:22 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 06 Aug 2019 22:04:22 +0000 Subject: [issue37741] importlib.metadata docs not showing up in the module index In-Reply-To: <1565125662.44.0.867092250529.issue37741@roundup.psfhosted.org> Message-ID: <85E28E2B-3C03-40DB-AF87-03A673C16F39@python.org> Barry A. Warsaw added the comment: I?ll do a PR for that too. > On Aug 6, 2019, at 14:07, Brett Cannon wrote: > > > Brett Cannon added the comment: > > If there's no porting benefit then let's move it to a single module instead of a package. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 18:39:01 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 06 Aug 2019 22:39:01 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565131141.0.0.539727597115.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: How do I write tests which only run for a given platform? Looking at test_crypt.py, I see that the crypt module is imported using test.support module so the exception will be raised even before the tests run. Is there a way to test imports? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 18:44:34 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 06 Aug 2019 22:44:34 +0000 Subject: [issue37741] importlib.metadata docs not showing up in the module index In-Reply-To: <1564685225.86.0.948746560612.issue37741@roundup.psfhosted.org> Message-ID: <1565131474.19.0.677148359052.issue37741@roundup.psfhosted.org> Change by Barry A. Warsaw : ---------- keywords: +patch pull_requests: +14887 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15153 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 18:58:15 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 06 Aug 2019 22:58:15 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1565132295.11.0.710194423988.issue37757@roundup.psfhosted.org> Barry A. Warsaw added the comment: > OTOH This would require a PEP change, formal review, etc. It would be trivial though. There are only two references to TargetScopeError in the PEP. One talks about adding the exception and the other just mentions it almost in passing as a subclass of SyntaxError. I think it would be better to just use SyntaxError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 19:34:35 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 06 Aug 2019 23:34:35 +0000 Subject: [issue37762] IDLE very slow due a super long line output in chunks In-Reply-To: <1565014260.07.0.714424226111.issue37762@roundup.psfhosted.org> Message-ID: <1565134475.97.0.666083016486.issue37762@roundup.psfhosted.org> Terry J. Reedy added the comment: For the general issue of interpreting control chars, see #23220 (and duplicate #24572). IDLE is a development environment, not a production environment. If Tal's hypothesis is correct, a solution for Bernard would be a new addition I want for Run Customized: 'Run with System Terminal'. The idea is that people who know the IDLE editor should be able to develop terminal-specific code in IDLE. Instead of Save, open or switch to Terminal/Command Prompt, enter 'python -i path/to/file.py, switch back to editor, one could hit Shift-F5, click [ ] Run with Terminal, click [OK]. The use cases are use of functions like Windows-only kbhit() and interpretation of output chars as on the default system console/terminal. The resolution for this issue should be that I open an issue so that others can contribute to doing this. As for what is happening with the keras output: The block character appears to be the Inverse Bullet character. Here are 1 and 3: '? ???'. In tk Text on Windows, the height and width depends on the font. In some, it is twice tall as wide, as at https://www.compart.com/en/unicode/U+25D8. Here are 1 and 3 \b backspaces: ' '. Firefox displays each as a square box with 0 0 0 8. On Windows, tk displays \b and many other control chars as a White Vertical Rectangle, https://www.compart.com/en/unicode/U+25af. Here are 1 and 3: '? ???', except that when representing backspaces, there is not the wide space between. In the png, the printable ascii runs overlap by 7 while the blob runs overlap by 6. If the blobs were \bs, there would seem to be 1 too few. Until Bernard copies and pastes the 'normal' output, or exactly describes it, if dynamic, and copies and pastes the 'wrong' tk output, I don't want to speculate further on what he saw. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 20:02:11 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 07 Aug 2019 00:02:11 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1565132295.11.0.710194423988.issue37757@roundup.psfhosted.org> Message-ID: Guido van Rossum added the comment: If you and Nick both feel strongly about this please take it to python-dev, I'm sure we'll get closure quickly there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 20:38:34 2019 From: report at bugs.python.org (Inada Naoki) Date: Wed, 07 Aug 2019 00:38:34 +0000 Subject: [issue34488] improve performance of BytesIO.writelines() by avoiding creation of unused PyLongs In-Reply-To: <1535133350.73.0.56676864532.issue34488@psf.upfronthosting.co.za> Message-ID: <1565138314.3.0.891310640904.issue34488@roundup.psfhosted.org> Inada Naoki added the comment: New changeset 3e41f3cabb661824a1a197116f7f5ead64eb6ced by Inada Naoki (Sergey Fedoseev) in branch 'master': bpo-34488: optimize BytesIO.writelines() (GH-8904) https://github.com/python/cpython/commit/3e41f3cabb661824a1a197116f7f5ead64eb6ced ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 20:39:51 2019 From: report at bugs.python.org (Inada Naoki) Date: Wed, 07 Aug 2019 00:39:51 +0000 Subject: [issue34488] improve performance of BytesIO.writelines() by avoiding creation of unused PyLongs In-Reply-To: <1535133350.73.0.56676864532.issue34488@psf.upfronthosting.co.za> Message-ID: <1565138391.22.0.182407253376.issue34488@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 Aug 6 20:41:19 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 07 Aug 2019 00:41:19 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565138479.84.0.82637510798.issue25172@roundup.psfhosted.org> Terry J. Reedy added the comment: I agree with Paul about the wording. Note that the proposed platform-specific catch and raise are for crypt.py, not test_crypt.py. If a test module should be skipped entirely, import_module is correct. For more refinement, test_idle has, for example, tk = import_module('tkinter') # Also imports _tkinter. if tk.TkVersion < 8.5: raise unittest.SkipTest("IDLE requires tk 8.5 or later.") Testing only continues if tkinter and _tkinter and tk >= 8.5. I presume that crypt = import_module('crypt') will only continue if crypt and _crypt, which is what you want. It is apparently not an error for _crypt to be missing on unix, just an inconvenience for people who expect it. FYI, Individual test classes and methods can be skipped with @unittest.skipIf(condition, message) # example @unittest.skipIf(sys.platform != 'darwin', 'test macOS-only code') See the unittest doc for more, though apparently not needed here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 20:56:25 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 07 Aug 2019 00:56:25 +0000 Subject: [issue37646] eval() in a list comprehension In-Reply-To: <1563751465.46.0.439346831661.issue37646@roundup.psfhosted.org> Message-ID: <1565139385.66.0.340285415828.issue37646@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 610a4823cc0a3c2380ad0dfe64ae483ced4e5304 by Raymond Hettinger in branch 'master': bpo-37646: Document that eval() cannot access nested scopes (GH-15117) https://github.com/python/cpython/commit/610a4823cc0a3c2380ad0dfe64ae483ced4e5304 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 20:57:14 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 07 Aug 2019 00:57:14 +0000 Subject: [issue37646] eval() in a list comprehension In-Reply-To: <1563751465.46.0.439346831661.issue37646@roundup.psfhosted.org> Message-ID: <1565139434.88.0.269200697792.issue37646@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14888 pull_request: https://github.com/python/cpython/pull/15155 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 21:08:02 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 07 Aug 2019 01:08:02 +0000 Subject: [issue37646] eval() in a list comprehension In-Reply-To: <1563751465.46.0.439346831661.issue37646@roundup.psfhosted.org> Message-ID: <1565140082.28.0.576107903942.issue37646@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 9341dcb4b9520ab92df10d4256e93a50e1e7d19f by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-37646: Document that eval() cannot access nested scopes (GH-15117) (GH-15155) https://github.com/python/cpython/commit/9341dcb4b9520ab92df10d4256e93a50e1e7d19f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 21:08:28 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 07 Aug 2019 01:08:28 +0000 Subject: [issue37646] eval() in a list comprehension In-Reply-To: <1563751465.46.0.439346831661.issue37646@roundup.psfhosted.org> Message-ID: <1565140108.61.0.333874104547.issue37646@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 21:36:03 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 07 Aug 2019 01:36:03 +0000 Subject: [issue37741] importlib.metadata docs not showing up in the module index In-Reply-To: <1564685225.86.0.948746560612.issue37741@roundup.psfhosted.org> Message-ID: <1565141763.02.0.596926849451.issue37741@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14889 pull_request: https://github.com/python/cpython/pull/15154 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 21:43:58 2019 From: report at bugs.python.org (wang xuancong) Date: Wed, 07 Aug 2019 01:43:58 +0000 Subject: [issue37780] A strange bug in eval() not present in Python 3 Message-ID: <1565142238.6.0.594105921359.issue37780@roundup.psfhosted.org> New submission from wang xuancong : We all know that since: [False, True, False].count(True) gives 1 eval('[False, True, False].count(True)') also gives 1. However, in Python 2, eval('[False, True, False].count(True)', {}, Counter()) gives 3, while eval('[False, True, False].count(True)', {}, {}) gives 1. Take note that a Counter is a special kind of defaultdict, which is again a special kind of dict. Thus, this should not alter the behaviour of eval(). This behaviour is correct in Python 3. ---------- components: Library (Lib) messages: 349146 nosy: xuancong84 priority: normal severity: normal status: open title: A strange bug in eval() not present in Python 3 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 22:07:14 2019 From: report at bugs.python.org (Inada Naoki) Date: Wed, 07 Aug 2019 02:07:14 +0000 Subject: [issue37781] Use "z" for PY_FORMAT_SIZE_T Message-ID: <1565143634.89.0.401096300573.issue37781@roundup.psfhosted.org> New submission from Inada Naoki : MSVC 2015 supports "z" for size_t format. I'm not sure about 2013. AIX support it too. Now "z" is portable enough. https://mail.python.org/archives/list/python-dev at python.org/thread/CAXKWESUIWJNJFLLXXWTQDUWTN3F7KOU/#QVSBYYICHYC3IFITF4QNMGIOLOGAQS6I ---------- messages: 349147 nosy: inada.naoki priority: normal severity: normal status: open title: Use "z" for PY_FORMAT_SIZE_T _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 22:07:37 2019 From: report at bugs.python.org (Inada Naoki) Date: Wed, 07 Aug 2019 02:07:37 +0000 Subject: [issue37781] Use "z" for PY_FORMAT_SIZE_T In-Reply-To: <1565143634.89.0.401096300573.issue37781@roundup.psfhosted.org> Message-ID: <1565143657.39.0.0525238331054.issue37781@roundup.psfhosted.org> Change by Inada Naoki : ---------- versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 22:09:21 2019 From: report at bugs.python.org (Inada Naoki) Date: Wed, 07 Aug 2019 02:09:21 +0000 Subject: [issue37781] Use "z" for PY_FORMAT_SIZE_T In-Reply-To: <1565143634.89.0.401096300573.issue37781@roundup.psfhosted.org> Message-ID: <1565143761.55.0.956467529605.issue37781@roundup.psfhosted.org> Change by Inada Naoki : ---------- keywords: +patch pull_requests: +14890 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15156 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 23:18:03 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 07 Aug 2019 03:18:03 +0000 Subject: [issue37780] A strange bug in eval() not present in Python 3 In-Reply-To: <1565142238.6.0.594105921359.issue37780@roundup.psfhosted.org> Message-ID: <1565147883.56.0.606976608476.issue37780@roundup.psfhosted.org> Raymond Hettinger added the comment: This isn't a bug. In Python 2, True and False are variable names rather than keywords. That means they can be shadowed: >>> False = 10 >>> True = 20 >>> [False, True] [10, 20] A Counter() is a kind a dictionary that returns zero rather than raising a KeyError. When you give eval() a Counter as a locals() dict, you're effectively shadowing the False and True variables: >>> eval('[False, True]', {}, Counter()) [0, 0] That follows from: >>> c = Counter() >>> c['True'] 0 >>> c['False'] 0 So effectively, your example translates to: >>> [0, 0, 0].count(0) 3 ---------- assignee: -> rhettinger nosy: +rhettinger resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 6 23:45:46 2019 From: report at bugs.python.org (Eryk Sun) Date: Wed, 07 Aug 2019 03:45:46 +0000 Subject: [issue31226] shutil.rmtree fails when target has an internal directory junction (Windows) In-Reply-To: <1502978298.87.0.60982184572.issue31226@psf.upfronthosting.co.za> Message-ID: <1565149546.5.0.248033078744.issue31226@roundup.psfhosted.org> Eryk Sun added the comment: > Junctions are sometimes used as links (e.g. mklink /j) and sometimes > as volume mount points (e.g. mountvol.exe). That people sometimes use junctions as if they're symlinks doesn't mean that we should pretend it's true. The reparse tag is IO_REPARSE_TAG_MOUNT_POINT, and they behave like mountpoints (volume mounts and bind mounts). See Junctions vs. Symlinks, below. It's potentially problematic to conflate junctions with symlinks. For example, a user who opts to use a junction instead of symlink may be denied the symlink privilege, so code that copies a junction as if it's a symlink will fail (e.g. move if os.rename fails, or copyfile with follow_symlinks=False, or copytree with symlinks=True), unless we add magical fallback code in os.symlink() to create junctions when the link target is a directory. Even if creating a symlink succeeds, a symlink has different behavior from that of a junction, which could lead to problems later on. That said, always traversing directory mountpoints as if they're just plain directories, like what Unix does, is not the norm in Windows. In some contexts, they're basically handled as symlinks -- in particular for a recursive delete. CMD's `rmdir /s`, and PowerShell's `remove-item -recurse -force`, and Explorer's folder deletion all remove junctions without traversing them, regardless of whether the target is a regular DOS path or a volume GUID name. For example, if we step through the disassembled code of `rmdir /s` in CMD (i.e. cmd!RmDirSlashS), we observe that it looks for the name-surrogate bit in the reparse tag to determine whether it should call RemoveDirectoryW on a reparse-point directory instead of traversing it. I would prefer to copy this behavior. It's safer, since standard users can create junctions to DOS paths and volume GUID names in Windows, unlike POSIX in which only the super user has the power to create mountpoints. While Windows mountvol.exe requires administrator access in order to update the mountpoint manager, CMD's `mklink /j` doesn't require elevated access, and neither does PowerShell's `new-item -itemtype junction`, even if the target is a volume GUID name. Maybe for Windows we can have a name-surrogate category based on the reparse tag's name-surrogate bit (i.e. bit 29, "the file or directory represents another named entity in the system"), as identified by the WINAPI macro IsReparseTagNameSurrogate (winnt.h). The surrogate type would be a superset of the symlink type and would be allowed to be a directory. Nothing would change with regard to symlinks proper, however. It would remain the case that only IO_REPARSE_TAG_SYMLINK reparse points would be classified as symlinks by stat(), islink(), readlink(), etc. In POSIX systems, the only surrogate file type would be the symlink type, which is never a directory. A keyword-only option surrogates_as_links=False could be added to stat() and lstat(). In POSIX, surrogates_as_links would be ignored. Given both follow_symlinks=False and surrogates_as_links=True, stat() would be able to return the reparse tag for any name-surrogate reparse point. The tag value could be added to _Py_stat_struct as st_reparse_tag, and the stat result tuple would be similarly extended. This field would be non-zero when querying any name-surrogate reparse point that's not followed. os.lstat(path, surrogates_as_links=True) could be the basis for os.path.issurrogate(). Or maybe we could add a more targeted function that calls CreateFileW and GetFileInformationByHandleEx: FileAttributeTagInfo, or FindFirstFileW. The scandir DirEntry result could implement an is_surrogate() method based on the reparse tag that's returned by FindFirstFileW. For _rmtree_unsafe, we could simply insert a test at the start to avoiding listing surrogate directories. For example: if os.path.issurrogate(path): entries = [] else: with os.scandir(path) as scandir_it: entries = list(scandir_it) We could also add an allow_directory_surrogates=False keyword-only option to os.remove, which would be ignored in POSIX just as the symlink() target_is_directory option is ignored in POSIX. By default calling os.remove on a non-symlink directory would fail, as one expects it should. Adding an option to remove a directory via os.remove isn't strictly consistent with POSIX, but os.remove was already modified in issue 18314 to always remove all junctions, so the behavior is already inconsistent. We'd be clearly specifying and documenting how it works, and hopefully the new requirement to pass the keyword option wouldn't be too disruptive for programs that have relied on the undocumented behavior. --- Junctions vs. Symlinks Junctions and symlinks have different constraints and behavior. Junctions can only target local devices, and when accessed remotely by a client they're evaluated remotely on the server (e.g. if a client accesses a junction to "C:\Temp" on a server, the target is the system drive on the server). Symlinks are always evaluated on the client side, i.e. the redirector sends the reparse request over the wire to the client. The evaluation of local and remote symlinks is set by policies on the client system. A local symlink may be allowed to target either a local device or a remote device. A remote symlink may be allowed to target either a remote device or a local device on the client (e.g. a symlink to "C:\Temp" on the server targets the system drive on the client). The policies that govern this are SymlinkLocalToLocalEvaluation (default enabled), SymlinkLocalToRemoteEvaluation (default disabled?), SymlinkRemoteToLocalEvaluation (default disabled), and SymlinkRemoteToRemoteEvaluation (default disabled). You might see these abbreviated as L2L, L2R, R2L, and R2R. Junction targets must be fully qualified, but symlinks can target relative paths. How relative symlinks interact with junctions vs symlinks demonstrates that junctions are intentionally designed to behave as mountpoints. For example, given "C:\test1\test2\foo_link" is a link to "..\foo", if we have a directory symlink "C:\symlink" that targets "C:\test1\test2", then "C:\symlink\foo_link" refers to "C:\test1\foo". In contrast, relative symlinks traverse a junction as a namespace grafting. So if we have a junction "C:\junction" that targets "C:\test1\test2" (the same target as the symlink), then "C:\junction\foo_link" refers to "C:\foo". If we set up a similar scenario in Linux using either a kernel bind mount or FUSE bindfs mount, we'll observe the same behavior. The bind mount is a name grafting in the virtual filesystem, whereas a symlink simply resolves to the target path. --- Mountpoints It seems to me that handling all junctions as mountpoints is more consistent with how we handle DOS and UNC drives as mountpoints even when they're not volume mountpoints. For example, we can map a directory such as "C:\Users\Public" to drive "P:" or share it as "\\Server\Public". These are similar to Unix bind mounts, but in the case of DOS and UNC drives the namespace grafting is internal to the system, either as junctions in the system object namespace (e.g. "\Sessions\0\DosDevices\\P:" -> "\Device\HarddiskVolume2\Users\Public") or as mappings in the UNC provider-share namespace (e.g. SMB shares, WebDAV shares, VirtualBox folder shares, and so on, all grafted under "\Device\Mup"). What's different about junction mountpoints is that they're not grafted as a root directory, whereas the syntax for DOS and UNC drives in Windows mandates that they're always the top-level root, i.e. we can't use ".." to traverse to a parent directory. Given this broader definition of a mountpoint, os.path.ismount would no longer call _getvolumepathname. It would still return true for DOS and UNC drive root directories. Otherwise it would simply check whether the path is a junction (i.e. IO_REPARSE_TAG_MOUNT_POINT). ---------- keywords: +needs review -patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 00:25:14 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Wed, 07 Aug 2019 04:25:14 +0000 Subject: [issue37772] zipfile.Path.iterdir() outputs sub directories many times or not at all In-Reply-To: <1565074650.65.0.762547380277.issue37772@roundup.psfhosted.org> Message-ID: <1565151914.52.0.961447310597.issue37772@roundup.psfhosted.org> Srinivas Nyayapati added the comment: I have attempted a fix to Path._add_implied_dirs and have the changes in my github branch https://github.com/shireenrao/cpython/tree/zipfile. Is it ok if I submitted a PR on this? I have run test_zipfile.py and the test case provided by J?rn Heissler successfully. ---------- nosy: +shireenrao _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 00:37:15 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 07 Aug 2019 04:37:15 +0000 Subject: [issue37004] SequenceMatcher.ratio() noncommutativity not well-documented In-Reply-To: <1558490955.4.0.899055526874.issue37004@roundup.psfhosted.org> Message-ID: <1565152635.51.0.877850059694.issue37004@roundup.psfhosted.org> miss-islington added the comment: New changeset e9cbcd0018abd2a5f2348c45d5c9c4265c4f42dc by Miss Islington (bot) (sweeneyde) in branch 'master': bpo-37004: Documented asymmetry of string arguments in difflib.SequenceMatcher for ratio method (GH-13482) https://github.com/python/cpython/commit/e9cbcd0018abd2a5f2348c45d5c9c4265c4f42dc ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 00:37:21 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 07 Aug 2019 04:37:21 +0000 Subject: [issue37004] SequenceMatcher.ratio() noncommutativity not well-documented In-Reply-To: <1558490955.4.0.899055526874.issue37004@roundup.psfhosted.org> Message-ID: <1565152641.8.0.0874599555535.issue37004@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14891 pull_request: https://github.com/python/cpython/pull/15157 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 00:37:28 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 07 Aug 2019 04:37:28 +0000 Subject: [issue37004] SequenceMatcher.ratio() noncommutativity not well-documented In-Reply-To: <1558490955.4.0.899055526874.issue37004@roundup.psfhosted.org> Message-ID: <1565152648.44.0.420048970584.issue37004@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14892 pull_request: https://github.com/python/cpython/pull/15158 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 00:37:34 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 07 Aug 2019 04:37:34 +0000 Subject: [issue37004] SequenceMatcher.ratio() noncommutativity not well-documented In-Reply-To: <1558490955.4.0.899055526874.issue37004@roundup.psfhosted.org> Message-ID: <1565152654.83.0.894826239641.issue37004@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14893 pull_request: https://github.com/python/cpython/pull/15159 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 03:16:04 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 07 Aug 2019 07:16:04 +0000 Subject: [issue24413] Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) raises NotImplementedError, but {}.keys().__or__(x) raises TypeError In-Reply-To: <1433827977.01.0.296186023212.issue24413@psf.upfronthosting.co.za> Message-ID: <1565162164.25.0.108047702227.issue24413@roundup.psfhosted.org> Serhiy Storchaka added the comment: set.update() accepts arbitrary iterable, but set.__or__() requires a set or frozenset. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 03:47:15 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 07 Aug 2019 07:47:15 +0000 Subject: [issue37779] configparser: add documentation about several read() behaviour In-Reply-To: <1565122960.66.0.217084239893.issue37779@roundup.psfhosted.org> Message-ID: <1565164035.15.0.451041732192.issue37779@roundup.psfhosted.org> Change by SilentGhost : ---------- components: +Cross-Build -Library (Lib) nosy: +Alex.Willmer stage: -> needs patch type: enhancement -> behavior versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 03:47:28 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 07 Aug 2019 07:47:28 +0000 Subject: [issue37779] configparser: add documentation about several read() behaviour In-Reply-To: <1565122960.66.0.217084239893.issue37779@roundup.psfhosted.org> Message-ID: <1565164048.02.0.0792093363451.issue37779@roundup.psfhosted.org> Change by SilentGhost : ---------- assignee: -> docs at python components: +Documentation -Cross-Build nosy: +docs at python -Alex.Willmer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 03:47:54 2019 From: report at bugs.python.org (Xianbo Wang) Date: Wed, 07 Aug 2019 07:47:54 +0000 Subject: [issue36338] urlparse of urllib returns wrong hostname In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org> Message-ID: <1565164074.83.0.663936524704.issue36338@roundup.psfhosted.org> Xianbo Wang added the comment: Python2 urlparse.urlparse and urllib2.urlparse.urlparse have a similar IPv6 hostname parsing bug. >>> urlparse.urlparse('http://nevil.com[]').hostname >>> 'evil.com[' This is less practical to exploit since the parsed domain contains a '[' in the end. Do I need to create a separate issue for this Python2 bug? I think the way PR 14896 fix the python3 bug can also be applied to this. Also, do we need a CVE ID for the python3 bug? As it may lead to some security issues in some Python apps, e.g., open-redirect. I have found such a case in a private bug bounty program. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 04:13:45 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Wed, 07 Aug 2019 08:13:45 +0000 Subject: [issue31388] Provide a way to defer SIGINT handling in the current thread In-Reply-To: <1504814605.12.0.216214618224.issue31388@psf.upfronthosting.co.za> Message-ID: <1565165625.06.0.365912746774.issue31388@roundup.psfhosted.org> Jeroen Demeyer added the comment: Another idea I had is to somehow deal with this in PyErr_WriteUnraisable: whenever PyErr_WriteUnraisable is called for a KeyboardInterrupt, defer that exception to a later time, for example when _PyEval_EvalFrameDefault() is called. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 05:00:58 2019 From: report at bugs.python.org (=?utf-8?q?D=C3=A1vid_Nemeskey?=) Date: Wed, 07 Aug 2019 09:00:58 +0000 Subject: [issue35786] get_lock() method is not present for Values created using multiprocessing.Manager() In-Reply-To: <1547934632.93.0.223661167179.issue35786@roundup.psfhosted.org> Message-ID: <1565168458.62.0.854655737827.issue35786@roundup.psfhosted.org> D?vid Nemeskey added the comment: Nothing in the documentation says that multiprocessing.Value and the object returned by manager.Value() is any different. Nor is it clear why they should be. It is perfectly understandable to expect that manager.Value() is actually of type multiprocessing.Value. It is also a valid assumption that the "canonical" way to acquire such objects are from a Manager, not directly. An example that reinforces this assumption is that of the Queue class, which HAS to be created through a Manager, lest we get "RuntimeError: Queue objects should only be shared between processes through inheritance". In conclusion, I think this is definitely a valid issue. What I am not so sure about is if it is (just) an issue in the documentation or the API itself. ---------- nosy: +nemeskeyd versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 05:03:56 2019 From: report at bugs.python.org (=?utf-8?q?D=C3=A1vid_Nemeskey?=) Date: Wed, 07 Aug 2019 09:03:56 +0000 Subject: [issue35786] get_lock() method is not present for Values created using multiprocessing.Manager() In-Reply-To: <1547934632.93.0.223661167179.issue35786@roundup.psfhosted.org> Message-ID: <1565168636.78.0.16449865165.issue35786@roundup.psfhosted.org> D?vid Nemeskey added the comment: OK, actually: trying to create a multiprocessing.Value object and sharing it between a Pool of processes results in "RuntimeError: Synchronized objects should only be shared between processes through inheritance". So the only way seems to be through a Manager, but its Value() is of a different class? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 05:32:13 2019 From: report at bugs.python.org (PBrudny) Date: Wed, 07 Aug 2019 09:32:13 +0000 Subject: [issue37782] typing.NamedTuple default parameter type issue Message-ID: <1565170333.28.0.690764361146.issue37782@roundup.psfhosted.org> New submission from PBrudny : There is an issue when NamedTuple parameter with default, which has not explicitly declared type is changed by keyword. Is that an expected behavior (no info https://docs.python.org/3.7/library/collections.html#collections.namedtuple) Used python release: Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32 test.py: from typing import NamedTuple class MyTestedTuple(NamedTuple): example_text = "default_text" example_int: int = 3 if __name__ == '__main__': print(MyTestedTuple().example_text) fault_tuple = MyTestedTuple(example_text="text_from_call") print(fault_tuple.example_text) Call: python test.py default_text Traceback (most recent call last): File "test.py", line 11, in fault_tuple = MyTestedTuple(example_text="text_from_call") TypeError: __new__() got an unexpected keyword argument 'example_text' ---------- components: Library (Lib) files: test.py messages: 349157 nosy: PBrudny priority: normal severity: normal status: open title: typing.NamedTuple default parameter type issue type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file48533/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 06:08:54 2019 From: report at bugs.python.org (=?utf-8?q?Philippe_N=C3=A9grel?=) Date: Wed, 07 Aug 2019 10:08:54 +0000 Subject: [issue37783] int returns error (SystemError) Message-ID: <1565172534.52.0.656651813313.issue37783@roundup.psfhosted.org> New submission from Philippe N?grel : Whenever I compile the code, I get this error: Exception has occurred: SystemError returned a result with an error set This issue occured at line 32 of the file "SaveTools.py" in this github branch: https://github.com/l3alr0g/Wave-simulator/tree/python-bug-report (sry I couldn't get the 'Github PR' option to work) ---------- components: Windows messages: 349158 nosy: Philippe N?grel, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: int returns error (SystemError) type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 06:11:52 2019 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 07 Aug 2019 10:11:52 +0000 Subject: [issue37782] typing.NamedTuple default parameter type issue In-Reply-To: <1565170333.28.0.690764361146.issue37782@roundup.psfhosted.org> Message-ID: <1565172712.05.0.248542452785.issue37782@roundup.psfhosted.org> Eric V. Smith added the comment: example_text is not a field, since you're not giving it a type. It's just a normal class member. The only field in the NamedTuple is example_int. You can't specify any other field in the call to MyTestedTuple(). To see this, help(MyTestedTuple) starts with: class MyTestedTuple(builtins.tuple) | MyTestedTuple(example_int: int = 3) ---------- nosy: +eric.smith resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 06:17:20 2019 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 07 Aug 2019 10:17:20 +0000 Subject: [issue37783] int returns error (SystemError) In-Reply-To: <1565172534.52.0.656651813313.issue37783@roundup.psfhosted.org> Message-ID: <1565173040.79.0.341710307769.issue37783@roundup.psfhosted.org> Eric V. Smith added the comment: This looks like a problem in pandas. If you can distill this down to a short python program that doesn't include any third party libraries, then we can take a look at it. Otherwise, I suggest reporting it on the pandas bug tracker. ---------- components: +Interpreter Core -Windows nosy: +eric.smith resolution: -> third party stage: -> test needed status: open -> pending type: compile error -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 06:19:41 2019 From: report at bugs.python.org (=?utf-8?q?Philippe_N=C3=A9grel?=) Date: Wed, 07 Aug 2019 10:19:41 +0000 Subject: [issue37783] int returns error (SystemError) In-Reply-To: <1565172534.52.0.656651813313.issue37783@roundup.psfhosted.org> Message-ID: <1565173181.28.0.0223736715171.issue37783@roundup.psfhosted.org> Philippe N?grel added the comment: My bad the compilation Error came from the panda3d engine, which affected in some way the int class, issue solved, sry for wasting your time X) ---------- resolution: third party -> not a bug stage: test needed -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 06:46:55 2019 From: report at bugs.python.org (Emmanuel Coirier) Date: Wed, 07 Aug 2019 10:46:55 +0000 Subject: [issue37784] Compiling Python 3 with sqlite impossible when sqlite installation is in a non standard directory Message-ID: <1565174815.9.0.140806109793.issue37784@roundup.psfhosted.org> New submission from Emmanuel Coirier : When compiling sqlite with a specific prefix, Python compilation process is unable to find sqlite despite CFLAGS and LDFLAGS environment variable correctly set. The problem is in the setup.py, in the detect_modules function or the detect_sqlite function. The sqlite_inc_paths list variable (line 1351) only contains well known places for sqlite, but there is no way to include others pathes (except by modifying the source code). The inc_dirs variable is also checked. But since it is not initialized with CFLAGS env_var, the CFLAGS -I pathes are not included, then not checked for a sqlite header file. This behavior forbids compiling and installing sqlite in a specific directory. Adding the sqlite3.h path in the detect_sqlite function allows sqlite to be included in the final python compilation and install and is a possible workaround. There should be a way to add this path to the detect_sqlite without having to edit the file on the fly in order to have a working sqlite module with a non standard sqlite install directory. On a side note, why installing sqlite in some random directory ? People don't always have right to write in /usr/lib and /usr/local/lib. ---------- components: Build, Extension Modules messages: 349162 nosy: manuco priority: normal severity: normal status: open title: Compiling Python 3 with sqlite impossible when sqlite installation is in a non standard directory type: compile error versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 07:07:54 2019 From: report at bugs.python.org (Mark Haase) Date: Wed, 07 Aug 2019 11:07:54 +0000 Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat() In-Reply-To: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org> Message-ID: <1565176074.16.0.828823983456.issue35829@roundup.psfhosted.org> Mark Haase added the comment: Defining isoformat() and fromisoformat() as functional inverses is misguided. Indeed, it's not even true: ``` Python 3.7.2 (default, Dec 28 2018, 14:27:11) [Clang 10.0.0 (clang-1000.11.45.5)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import datetime >>> s = '2019-08-07t10:44:00+00:00' >>> assert s == datetime.isoformat(datetime.fromisoformat(s)) Traceback (most recent call last): File "", line 1, in AssertionError ``` I agree with rdb that not parsing "Z" is inconvenient and counter intuitive. We have the same use case: parsing ISO strings created by JavaScript (or created by systems that interoperate with JavaScript). We have also memorized the same `.replace("Z", "+00:00")` hack, but this feels like a missing battery in the stdlib. As Paul points out the legacy of isoformat() complicates the situation. A new pair of functions for RFC-3339 sounds reasonable to me, either rfcformat()/fromrfcformat() or more boldly inetformat()/frominetformat(). The contracts for these functions are simple: fromrfcformat() parses RFC-3339 strings, and rfcformat() produces an RFC-3339 string. The docs for the ISO functions should be updated to point towards the RFC-compliant functions. I'd be willing to work on a PR, but a change of this size probably needs to through python-ideas first? ---------- nosy: +mehaase _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 08:31:12 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 07 Aug 2019 12:31:12 +0000 Subject: [issue37779] configparser: add documentation about several read() behaviour In-Reply-To: <1565122960.66.0.217084239893.issue37779@roundup.psfhosted.org> Message-ID: <1565181072.3.0.947792353728.issue37779@roundup.psfhosted.org> Joannah Nanjekye added the comment: @St?phane, thanks for suggesting the above documentation. Feel free to open a pull request here: https://github.com/python/cpython with this draft for review. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 08:37:06 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 07 Aug 2019 12:37:06 +0000 Subject: [issue37779] configparser: add documentation about several read() behaviour In-Reply-To: <1565122960.66.0.217084239893.issue37779@roundup.psfhosted.org> Message-ID: <1565181426.53.0.0938362159418.issue37779@roundup.psfhosted.org> Joannah Nanjekye added the comment: I think you can build on the story in the quick start section. You can build on from the last section that starts with the paragraph: Now that we have created and saved a configuration file, let?s read it back and explore the data it holds. As it has some examples on read(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 08:49:16 2019 From: report at bugs.python.org (Jakub Kulik) Date: Wed, 07 Aug 2019 12:49:16 +0000 Subject: [issue37785] argparse uses %s in gettext calls Message-ID: <1565182156.22.0.512922989842.issue37785@roundup.psfhosted.org> New submission from Jakub Kulik : Running xgettext on argparse.py (of any currently supported Python 3.x) return following warning: ./Lib/argparse.py: warning: 'msgid' format string with unnamed arguments cannot be properly localized: The translator cannot reorder the arguments. Please consider using a format string with named arguments, and a mapping instead of a tuple for the arguments. Same problem was already partially fixed here: https://bugs.python.org/issue10528. I guess that this occurrence was either missed or is new since. It would be nice to have this backported to all supported releases but considering incompatibility worries in issue linked above, it may be fixed only in 3.8+ (which is still nice). ---------- components: Library (Lib) messages: 349166 nosy: kulikjak priority: normal severity: normal status: open title: argparse uses %s in gettext calls versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 08:51:34 2019 From: report at bugs.python.org (Jakub Kulik) Date: Wed, 07 Aug 2019 12:51:34 +0000 Subject: [issue37785] argparse uses %s in gettext calls causing xgettext warnings In-Reply-To: <1565182156.22.0.512922989842.issue37785@roundup.psfhosted.org> Message-ID: <1565182294.7.0.805901515995.issue37785@roundup.psfhosted.org> Change by Jakub Kulik : ---------- title: argparse uses %s in gettext calls -> argparse uses %s in gettext calls causing xgettext warnings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 08:52:57 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 07 Aug 2019 12:52:57 +0000 Subject: [issue14019] Unify tests for str.format and string.Formatter In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za> Message-ID: <1565182377.7.0.576297302277.issue14019@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 08:53:02 2019 From: report at bugs.python.org (Jakub Kulik) Date: Wed, 07 Aug 2019 12:53:02 +0000 Subject: [issue37785] argparse uses %s in gettext calls causing xgettext warnings In-Reply-To: <1565182156.22.0.512922989842.issue37785@roundup.psfhosted.org> Message-ID: <1565182382.46.0.294587039815.issue37785@roundup.psfhosted.org> Change by Jakub Kulik : ---------- keywords: +patch pull_requests: +14894 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15161 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 08:56:36 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 07 Aug 2019 12:56:36 +0000 Subject: [issue37438] ConfigParser.set() docs should mention allow_no_value In-Reply-To: <1561713800.79.0.286500391609.issue37438@roundup.psfhosted.org> Message-ID: <1565182596.58.0.256703356851.issue37438@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 08:59:49 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 07 Aug 2019 12:59:49 +0000 Subject: [issue15371] test_cmd_line_script should include namespace package tests In-Reply-To: <1342448877.31.0.875625357245.issue15371@psf.upfronthosting.co.za> Message-ID: <1565182789.33.0.769538281211.issue15371@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 10:23:59 2019 From: report at bugs.python.org (Paul Francis) Date: Wed, 07 Aug 2019 14:23:59 +0000 Subject: [issue37786] Doesn't delete PATH from System Variables (uninstallation) Message-ID: <1565187839.39.0.765902255643.issue37786@roundup.psfhosted.org> New submission from Paul Francis : Neither the 32bit nor the 64bit version of Python 3.7.4 will remove the PATH variables from the System Environment Variables of the O/S even though the uninstallation screen explicitly displays a message that infers it is doing so. Windows 10 Pro x64 v1903 ---------- components: Windows messages: 349167 nosy: Paul Francis, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Doesn't delete PATH from System Variables (uninstallation) type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 10:54:43 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Wed, 07 Aug 2019 14:54:43 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1565189683.58.0.351980459054.issue34679@roundup.psfhosted.org> Change by ?ukasz Langa : ---------- nosy: +lukasz.langa, ned.deily priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 11:32:45 2019 From: report at bugs.python.org (Kevin Braun) Date: Wed, 07 Aug 2019 15:32:45 +0000 Subject: [issue37787] Minimum denormal or ** bug Message-ID: <1565191965.7.0.701349886261.issue37787@roundup.psfhosted.org> New submission from Kevin Braun : Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05) [MSC v.1916 64 bit (AMD64)] I believe 2**-1074 is the smallest denormalized number for Python on my system (Windows), so I would expect 2**-1075 to yield 0.0, but it does not. Instead: >>> 2**-1074==2**-1075 True >>> (2**-1074).hex() '0x0.0000000000001p-1022' >>> (2**-1075).hex() '0x0.0000000000001p-1022' And, the above is not consistent with the following: >>> (2**-1074)/2 0.0 >>> (2**-1074)/2 == 2**-1075 False >>> 1/2**1075 0.0 >>> 1/2**1075 == 2**-1075 False Given the above observations, I suspect there is a bug in **. ---------- components: Interpreter Core messages: 349168 nosy: Kevin Braun priority: normal severity: normal status: open title: Minimum denormal or ** bug type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 11:39:36 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 07 Aug 2019 15:39:36 +0000 Subject: [issue37004] SequenceMatcher.ratio() noncommutativity not well-documented In-Reply-To: <1558490955.4.0.899055526874.issue37004@roundup.psfhosted.org> Message-ID: <1565192376.01.0.836077309125.issue37004@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset 1a3a40c1cb582e436d568009fae2b06c0b1978ed by Terry Jan Reedy (Miss Islington (bot)) in branch '3.8': bpo-37004: Documented asymmetry of string arguments in difflib.SequenceMatcher for ratio method (GH-13482) (#15157) https://github.com/python/cpython/commit/1a3a40c1cb582e436d568009fae2b06c0b1978ed ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 11:39:52 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 07 Aug 2019 15:39:52 +0000 Subject: [issue37004] SequenceMatcher.ratio() noncommutativity not well-documented In-Reply-To: <1558490955.4.0.899055526874.issue37004@roundup.psfhosted.org> Message-ID: <1565192392.53.0.90420184706.issue37004@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset 7dafbe81bd0afb8bd67bc3a4c851a6c728fd87fe by Terry Jan Reedy (Miss Islington (bot)) in branch '3.7': bpo-37004: Documented asymmetry of string arguments in difflib.SequenceMatcher for ratio method (GH-13482) (#15158) https://github.com/python/cpython/commit/7dafbe81bd0afb8bd67bc3a4c851a6c728fd87fe ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 11:42:07 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 07 Aug 2019 15:42:07 +0000 Subject: [issue37787] Minimum denormal or ** bug In-Reply-To: <1565191965.7.0.701349886261.issue37787@roundup.psfhosted.org> Message-ID: <1565192527.86.0.221887041682.issue37787@roundup.psfhosted.org> SilentGhost added the comment: This seems like a Windows-specific issues. Using the same version of python built with gcc 8.3, I get the results inline with your expectations and all the comparisons yield exactly opposite values. ---------- components: +Windows nosy: +SilentGhost, paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 11:57:43 2019 From: report at bugs.python.org (Tim Peters) Date: Wed, 07 Aug 2019 15:57:43 +0000 Subject: [issue37787] Minimum denormal or ** bug In-Reply-To: <1565191965.7.0.701349886261.issue37787@roundup.psfhosted.org> Message-ID: <1565193463.56.0.867153414482.issue37787@roundup.psfhosted.org> Tim Peters added the comment: Python delegates exponentiation with a Python float result to the platform C's double precision `pow()` function. So this is just what the Windows C pow(2.0, -1075.0) returns. All native floating point operations are subject various kinds of error, and this is one. >>> import math >>> math.pow(2.0, -1075.0) 5e-324 >>> math.pow(2.0, -1074.0) # same thing 5e-324 To avoid intermediate libm rounding errors, use ldexp instead: >>> math.ldexp(1, -1074) # 2.0 ** -1074 5e-324 >>> math.ldexp(1, -1075) # 2.0 ** -1075 0.0 ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 12:13:49 2019 From: report at bugs.python.org (Tim Peters) Date: Wed, 07 Aug 2019 16:13:49 +0000 Subject: [issue37004] SequenceMatcher.ratio() noncommutativity not well-documented In-Reply-To: <1558490955.4.0.899055526874.issue37004@roundup.psfhosted.org> Message-ID: <1565194429.31.0.668670755745.issue37004@roundup.psfhosted.org> Change by Tim Peters : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 12:22:52 2019 From: report at bugs.python.org (Anselm Kruis) Date: Wed, 07 Aug 2019 16:22:52 +0000 Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak Message-ID: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org> New submission from Anselm Kruis : Starting with commit 468e5fec (bpo-36402: Fix threading._shutdown() race condition (GH-13948)) the following trivial test case leaks one reference and one memory block. class MiscTestCase(unittest.TestCase): def test_without_join(self): # Test that a thread without join does not leak references. # Use a debug build and run "python -m test -R: test_threading" threading.Thread().start() Attached is a patch, that adds this test case to Lib/test/test_threading.py. After you apply this patch "python -m test -R: test_threading" leaks one (additional) reference. This leak is also present in Python 3.7.4 and 3.8. I'm not sure, if it correct not to join a thread, but it did work flawlessly and didn't leak in previous releases. I didn't analyse the root cause yet. ---------- components: Library (Lib) files: threading-leak-test-case.diff keywords: patch messages: 349173 nosy: anselm.kruis priority: normal severity: normal status: open title: fix for bpo-36402 (threading._shutdown() race condition) causes reference leak type: resource usage versions: Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file48534/threading-leak-test-case.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 12:33:46 2019 From: report at bugs.python.org (Christopher Brousseau) Date: Wed, 07 Aug 2019 16:33:46 +0000 Subject: [issue37745] 3.8b3 - windows install gui/ inconsistent options In-Reply-To: <1564766468.14.0.320547199271.issue37745@roundup.psfhosted.org> Message-ID: <1565195626.94.0.892315088525.issue37745@roundup.psfhosted.org> Christopher Brousseau added the comment: Ah - I didn't realize the nuances here - thank you for clearing that up for me. Understand the design goal of keeping window size and using only checkboxes - simple. Also agree some text changes may help, here are some suggestions for your consideration: screen 1 - install python recommend we change "install launcher" to "install py launcher" to be explicit. Long term - it would be cleaner if the user had only 'default' and customize installation on this screen, with all configurations either bundled under Default, or moved to other screens for 'Customized' installs. We could add notes under default that we're installing python for all users, py launcher, adding Python to PATH, etc. If a user does not have admin privileges, it may not be helpful to them to present choices they can't install. For a default install - we could test if user has admin privileges and install for all users, or fall back to 'user' only install. screen 2 - optional features recommend we move "for all users" to screen 3, since this screen is about features to add, while the following screen is about how they are configured on the system. If this isn't possible in this release, consider 1. changing current "py launcher" checkbox to "upgrade py launcher" 2. moving "for all users" to next line down - looks like we have space 3. changing "for all users" to "py launcher for all users" screen 3 - advanced options two recommendations: 1. change "install for all users" to "install python for all users" 2. insert checkbox for "install py launcher for all users" as 2nd item in list. This would then be directly above the existing "Associate files with Python" checkbox ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:06:36 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 07 Aug 2019 17:06:36 +0000 Subject: [issue37745] 3.8b3 - windows install gui/ inconsistent options In-Reply-To: <1564766468.14.0.320547199271.issue37745@roundup.psfhosted.org> Message-ID: <1565197596.65.0.499044902545.issue37745@roundup.psfhosted.org> Steve Dower added the comment: > recommend we change "install launcher" to "install py launcher" to be explicit. To be clear, you mean we change "Install launcher for all users" to "Install py launcher for all users"? You get the launcher by default regardless, the only choice here is whether _everyone_ on your machine gets it (and you need to be an admin). > Long term - it would be cleaner if the user had only 'default' and customize installation on this screen, with all configurations either bundled under Default, or moved to other screens for 'Customized' installs. We could add notes under default that we're installing python for all users, py launcher, adding Python to PATH, etc. This is where we started, and the notes are already there. What changed is: * we don't add Python to PATH by default (because it's bad), and people couldn't find the option * we had to replace the 3.4 py.exe launcher, which was always for all users, while making it easy for non-admins to install Python > If a user does not have admin privileges, it may not be helpful to them to present choices they can't install. For a default install - we could test if user has admin privileges and install for all users, or fall back to 'user' only install. This is not possible. Most users do not start with admin privileges, but when prompted can provide them (via UAC). What we have here is the best we can offer without requiring complicated leaps of understanding for every type of user. > recommend we move "for all users" to screen 3, since this screen is about features to add, while the following screen is about how they are configured on the system. To clarify, we add an "Install py launcher for all users" checkbox on screen 3 and remove it from screen 2? What gets removed from screen 3 to make space for it? > 1. changing current "py launcher" checkbox to "upgrade py launcher" But this is incorrect. If you don't select the checkbox, you don't get the launcher. It's a choice to have or not-have, not a choice to upgrade or not-upgrade. > 2. moving "for all users" to next line down - looks like we have space > 3. changing "for all users" to "py launcher for all users" This is feasible, but not high priority. PRs welcome. > 1. change "install for all users" to "install python for all users" Trivial - the string is in one of the .wxl files in Tools/msi/bundle (I forget which one right now). > 2. insert checkbox for "install py launcher for all users" as 2nd item in list. This would then be directly above the existing "Associate files with Python" checkbox Instead of the "for all users" on the previous page? This should be straightforward as well, as the enable/disable logic should be the same as for the current one. A change to one of the .thm files, IIRC. But all this is going to take someone motivated enough to contribute and test it. Right now, I have higher priority issues to spend my limited volunteer time on than the traditional installer. I can review PRs though (ideally including real screenshots so I don't also have to do the manual testing myself). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:07:14 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 07 Aug 2019 17:07:14 +0000 Subject: [issue37786] Doesn't delete PATH from System Variables (uninstallation) In-Reply-To: <1565187839.39.0.765902255643.issue37786@roundup.psfhosted.org> Message-ID: <1565197634.59.0.154675536069.issue37786@roundup.psfhosted.org> Steve Dower added the comment: Duplicate of issue28576 ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Uninstalling Py352 x86 with /uninstall option does not remove prepended paths _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:14:04 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 07 Aug 2019 17:14:04 +0000 Subject: [issue37787] Minimum denormal or ** bug In-Reply-To: <1565191965.7.0.701349886261.issue37787@roundup.psfhosted.org> Message-ID: <1565198044.86.0.708752101963.issue37787@roundup.psfhosted.org> Steve Dower added the comment: I have nothing to contribute here. Tim's right. (I would love Python to have infinite precision float by default...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:31:16 2019 From: report at bugs.python.org (hai shi) Date: Wed, 07 Aug 2019 17:31:16 +0000 Subject: [issue37718] 2to3 exception handling In-Reply-To: <1564475098.96.0.917553706699.issue37718@roundup.psfhosted.org> Message-ID: <1565199076.52.0.922072564727.issue37718@roundup.psfhosted.org> hai shi added the comment: 1. the message property of PyBaseExceptionObject(Exception) have been cancelled. [1] https://github.com/python/cpython/blob/2.7/Include/pyerrors.h#L13 [2] https://github.com/python/cpython/blob/master/Include/cpython/pyerrors.h#L18 2. `except Exception, e` is a python2.x behavior, pls use `except Exception as e` in python3.x ---------- nosy: +shihai1991 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:32:30 2019 From: report at bugs.python.org (Peter Edwards) Date: Wed, 07 Aug 2019 17:32:30 +0000 Subject: [issue35484] Segmentation fault due to faulthandler on Solaris In-Reply-To: <1544715488.9.0.788709270274.issue35484@psf.upfronthosting.co.za> Message-ID: <1565199150.24.0.264202543071.issue35484@roundup.psfhosted.org> Peter Edwards added the comment: This is likely a duplicate of issue 21131 ---------- nosy: +peadar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:40:20 2019 From: report at bugs.python.org (Tim Peters) Date: Wed, 07 Aug 2019 17:40:20 +0000 Subject: [issue37787] Minimum denormal or ** bug In-Reply-To: <1565191965.7.0.701349886261.issue37787@roundup.psfhosted.org> Message-ID: <1565199620.51.0.515620470063.issue37787@roundup.psfhosted.org> Tim Peters added the comment: Since this depends on the platform libm implementation of pow(), I'm closing this as "won't fix". Steve, on the chance you're serious ;-) , there are implementations of the "constructive reals", which indeed act like infinite-precision floats. But they tend to be very slow, and, e.g., testing two of them for equality is, in general, undecidable even in theory. Here's one such: https://www.chiark.greenend.org.uk/~sgtatham/spigot/ ---------- resolution: -> wont fix stage: -> resolved status: open -> closed versions: -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:45:42 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 07 Aug 2019 17:45:42 +0000 Subject: [issue37787] Minimum denormal or ** bug In-Reply-To: <1565191965.7.0.701349886261.issue37787@roundup.psfhosted.org> Message-ID: <1565199942.04.0.49150120842.issue37787@roundup.psfhosted.org> Steve Dower added the comment: Only half serious ;) I'd settle for "reliable, consistent and easy to explain rounding", which is unfortunately not what IEEE 754 provides (unless you assume significant amounts of CS background that most Python users do not have). But then, nothing else really provides it either, so it's more of a dream than a plan :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:49:46 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 07 Aug 2019 17:49:46 +0000 Subject: [issue37734] Registry keys for Windows Store package have wrong executable In-Reply-To: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org> Message-ID: <1565200186.93.0.807120435512.issue37734@roundup.psfhosted.org> Steve Dower added the comment: New changeset 1fab9cbfbaf19a7bc79cef382136fcf9491e3183 by Steve Dower in branch 'master': bpo-37734: Fix use of registry values to launch Python from Microsoft Store app (GH-15146) https://github.com/python/cpython/commit/1fab9cbfbaf19a7bc79cef382136fcf9491e3183 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:50:00 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 07 Aug 2019 17:50:00 +0000 Subject: [issue37734] Registry keys for Windows Store package have wrong executable In-Reply-To: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org> Message-ID: <1565200200.99.0.0948945812838.issue37734@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14895 pull_request: https://github.com/python/cpython/pull/15163 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:50:20 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 07 Aug 2019 17:50:20 +0000 Subject: [issue37778] Windows Store package uses wrong icons for file association In-Reply-To: <1565122034.52.0.620169066443.issue37778@roundup.psfhosted.org> Message-ID: <1565200220.5.0.0488796836604.issue37778@roundup.psfhosted.org> Steve Dower added the comment: New changeset 87ce9588ceb4b4dd625913344844390f0b991b0c by Steve Dower in branch 'master': bpo-37778: Fixes the icons used for file associations to the Microsoft Store package (GH-15150) https://github.com/python/cpython/commit/87ce9588ceb4b4dd625913344844390f0b991b0c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:50:28 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 07 Aug 2019 17:50:28 +0000 Subject: [issue37778] Windows Store package uses wrong icons for file association In-Reply-To: <1565122034.52.0.620169066443.issue37778@roundup.psfhosted.org> Message-ID: <1565200228.89.0.975036558065.issue37778@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14896 pull_request: https://github.com/python/cpython/pull/15164 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:50:34 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 07 Aug 2019 17:50:34 +0000 Subject: [issue37496] Support annotations in signature strings. In-Reply-To: <1562197526.36.0.0415942737779.issue37496@roundup.psfhosted.org> Message-ID: <1565200234.6.0.751465113087.issue37496@roundup.psfhosted.org> Ivan Levkivskyi added the comment: > I have a couple of questions about how to use `ast_unparse.c`'s `expr_as_unicode` function: > 1. Should I create a new function in the `ast` module that exposes that C function in Python in order to use it in `Lib/inspect.py`? > 2. Would it be better to just re-use the _AST to string_ implementation in `Tools/unparse.py`? Hm, TBH I am not sure which one is better, I am leaning towards option 1, but I add more people to get some opinions. ---------- nosy: +gvanrossum, lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:55:09 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 07 Aug 2019 17:55:09 +0000 Subject: [issue37734] Registry keys for Windows Store package have wrong executable In-Reply-To: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org> Message-ID: <1565200509.98.0.818757388473.issue37734@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +14897 pull_request: https://github.com/python/cpython/pull/15165 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:55:31 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 07 Aug 2019 17:55:31 +0000 Subject: [issue15987] Provide a way to compare AST nodes for equality recursively In-Reply-To: <1348166637.22.0.281544835659.issue15987@psf.upfronthosting.co.za> Message-ID: <1565200531.17.0.791655400812.issue15987@roundup.psfhosted.org> Ivan Levkivskyi added the comment: > If consensus has been reached on this, I am willing to do the work. It looks like there is already an active PR https://github.com/python/cpython/pull/14970, there are some non-implemented comments from a core review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 13:59:59 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Wed, 07 Aug 2019 17:59:59 +0000 Subject: [issue11165] Document PyEval_Call* functions In-Reply-To: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za> Message-ID: <1565200799.48.0.553573462539.issue11165@roundup.psfhosted.org> Jeroen Demeyer added the comment: These functions are now officially deprecated, see PR 14804. So I think that this issue can be closed. ---------- nosy: +jdemeyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 14:07:48 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 07 Aug 2019 18:07:48 +0000 Subject: [issue37734] Registry keys for Windows Store package have wrong executable In-Reply-To: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org> Message-ID: <1565201268.05.0.0777405126639.issue37734@roundup.psfhosted.org> miss-islington added the comment: New changeset eab76c3c75a572566862200728cc8d05b3298f12 by Miss Islington (bot) in branch '3.8': bpo-37734: Fix use of registry values to launch Python from Microsoft Store app (GH-15146) https://github.com/python/cpython/commit/eab76c3c75a572566862200728cc8d05b3298f12 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 14:15:20 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 07 Aug 2019 18:15:20 +0000 Subject: [issue37778] Windows Store package uses wrong icons for file association In-Reply-To: <1565122034.52.0.620169066443.issue37778@roundup.psfhosted.org> Message-ID: <1565201720.04.0.513589265495.issue37778@roundup.psfhosted.org> miss-islington added the comment: New changeset dc6653fd06598f42b107dcffcd089d7ee2b1cd44 by Miss Islington (bot) in branch '3.8': bpo-37778: Fixes the icons used for file associations to the Microsoft Store package (GH-15150) https://github.com/python/cpython/commit/dc6653fd06598f42b107dcffcd089d7ee2b1cd44 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 14:39:18 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 07 Aug 2019 18:39:18 +0000 Subject: [issue37734] Registry keys for Windows Store package have wrong executable In-Reply-To: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org> Message-ID: <1565203158.29.0.205572049947.issue37734@roundup.psfhosted.org> Steve Dower added the comment: New changeset 0378d98678f3617fd44d9a6266e7c17ebce62755 by Steve Dower in branch 'master': bpo-37734: Remove unnecessary brace escapes in PC/layout script (GH-15165) https://github.com/python/cpython/commit/0378d98678f3617fd44d9a6266e7c17ebce62755 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 14:39:20 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 07 Aug 2019 18:39:20 +0000 Subject: [issue37734] Registry keys for Windows Store package have wrong executable In-Reply-To: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org> Message-ID: <1565203160.71.0.448302863124.issue37734@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14898 pull_request: https://github.com/python/cpython/pull/15166 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 14:44:56 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 07 Aug 2019 18:44:56 +0000 Subject: [issue37685] Fix equality checks for some types In-Reply-To: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org> Message-ID: <1565203496.95.0.639828139337.issue37685@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +14899 pull_request: https://github.com/python/cpython/pull/15167 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 14:47:40 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 07 Aug 2019 18:47:40 +0000 Subject: [issue37778] Windows Store package uses wrong icons for file association In-Reply-To: <1565122034.52.0.620169066443.issue37778@roundup.psfhosted.org> Message-ID: <1565203660.52.0.73081944815.issue37778@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 14:48:53 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 07 Aug 2019 18:48:53 +0000 Subject: [issue37734] Registry keys for Windows Store package have wrong executable In-Reply-To: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org> Message-ID: <1565203733.22.0.571842680741.issue37734@roundup.psfhosted.org> Steve Dower added the comment: Going to leave this open in commit review for now. I believe this will significantly improve the reliability, but depending on which Windows bugs people run into there may still be more things we can do. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 14:54:01 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 07 Aug 2019 18:54:01 +0000 Subject: [issue35786] get_lock() method is not present for Values created using multiprocessing.Manager() In-Reply-To: <1547934632.93.0.223661167179.issue35786@roundup.psfhosted.org> Message-ID: <1565204041.78.0.746819210248.issue35786@roundup.psfhosted.org> Josh Rosenberg added the comment: Reading the docs, I'd definitely expect multiprocessing.Manager().Value to obey the same interface as multiprocessing.Value. The SyncManager docs say: > Its methods create and return Proxy Objects for a number of commonly used data types to be synchronized across processes. It does also say (under the linked definition for Proxy Objects): > A proxy object has methods which invoke corresponding methods of its referent (although not every method of the referent will necessarily be available through the proxy). which implies the proxy might be more limited, but in fact the proxy is wrapping a completely different underlying class, multiprocessing.managers.Value (that has nothing to do with the class you'd get from calling multiprocessing.Value or multiprocessing.sharedctypes.Value). It looks like there was, at some point, an attempt to make certain interfaces match; multiprocessing.managers.Value's initializer has a prototype of: def __init__(self, typecode, value, lock=True): (documented prototype excludes the lock argument), but AFAICT, lock is completely ignored, and typecode is stored as _typecode on the underlying Value, but otherwise ignored; the multiprocessing.managers.ValueProxy object returned by manager.Value() doesn't expose it (except insofar as you can call ._getvalue() on it to retrieve a copy of the underlying Value), and even if you get the unwrapped object, all _typecode does is change the repr; it's not used anywhere else. It seems like SyncManager.Value is just the worst of all possible worlds; it has a prototype that (roughly) matches multiprocessing.Value/multiprocessing.sharedctypes.Value, and the limited documentation implies it serves the same function, but: 1. It effectively ignores every argument aside from value (which is the second argument, so you're stuck passing the first argument even though nothing uses it) 2. It doesn't actually use ctypes to achieve efficient storage/IPC communication (updating value involves pickling it, not just sending the raw data of a C array/struct) 3. It doesn't provide any of the interface of the other Value, so you can't use get_lock (or use a with statement to lock it, or manually call acquire or release) or get_obj. I'm not sure what to do about it though; the manager version of Value is much more flexible, and I'm sure there is existing code that takes advantage of that, so we can't rewrite to make it ctypes backed. The multiprocessing.managers code is too new/complex for me to determine if any easy solution exists to expand multiprocessing.managers.ValueProxy to support context management/get_lock/get_obj to match the behavior of the class returned by multiprocessing.Value/multiprocessing.sharedctypes.Value, but it seems like, if we're going to let the docs imply a relationship, we ought to at least try to make the API of the two classes roughly match. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 14:59:12 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 07 Aug 2019 18:59:12 +0000 Subject: [issue37734] Registry keys for Windows Store package have wrong executable In-Reply-To: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org> Message-ID: <1565204352.84.0.827618839699.issue37734@roundup.psfhosted.org> miss-islington added the comment: New changeset 84d31bbf1f7e10bde1ceadcfa0d83d30a04313d5 by Miss Islington (bot) in branch '3.8': bpo-37734: Remove unnecessary brace escapes in PC/layout script (GH-15165) https://github.com/python/cpython/commit/84d31bbf1f7e10bde1ceadcfa0d83d30a04313d5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 15:22:07 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 07 Aug 2019 19:22:07 +0000 Subject: [issue37789] Update doc strings for test.bytecode_helper Message-ID: <1565205727.21.0.329229994167.issue37789@roundup.psfhosted.org> New submission from Joannah Nanjekye : I want to believe there is a mistake in the doc strings for these methods: def assertInBytecode(self, x, opname, argval=_UNSPECIFIED): """Returns instr if op is found, otherwise throws AssertionError""" for instr in dis.get_instructions(x): if instr.opname == opname: if argval is _UNSPECIFIED or instr.argval == argval: return instr disassembly = self.get_disassembly_as_string(x) if argval is _UNSPECIFIED: msg = '%s not found in bytecode:\n%s' % (opname, disassembly) else: msg = '(%s,%r) not found in bytecode:\n%s' msg = msg % (opname, argval, disassembly) self.fail(msg) def assertNotInBytecode(self, x, opname, argval=_UNSPECIFIED): """Throws AssertionError if op is found""" for instr in dis.get_instructions(x): if instr.opname == opname: disassembly = self.get_disassembly_as_string(x) if argval is _UNSPECIFIED: msg = '%s occurs in bytecode:\n%s' % (opname, disassembly) elif instr.argval == argval: msg = '(%s,%r) occurs in bytecode:\n%s' msg = msg % (opname, argval, disassembly) self.fail(msg) It is supported to refer to *opname* not *op*. Either the method signatures or the doc strings have to be updated. I stand to be corrected If wrong though. ---------- messages: 349193 nosy: nanjekyejoannah priority: normal severity: normal status: open title: Update doc strings for test.bytecode_helper _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 15:22:23 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 07 Aug 2019 19:22:23 +0000 Subject: [issue37789] Update doc strings for test.bytecode_helper In-Reply-To: <1565205727.21.0.329229994167.issue37789@roundup.psfhosted.org> Message-ID: <1565205743.07.0.331374927427.issue37789@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 15:22:55 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 07 Aug 2019 19:22:55 +0000 Subject: [issue37789] Update doc strings for test.bytecode_helper In-Reply-To: <1565205727.21.0.329229994167.issue37789@roundup.psfhosted.org> Message-ID: <1565205775.56.0.0848280748313.issue37789@roundup.psfhosted.org> Joannah Nanjekye added the comment: *supposed not supported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 15:31:54 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 07 Aug 2019 19:31:54 +0000 Subject: [issue18578] Rename and document test.bytecode_helper as test.support.bytecode_helper In-Reply-To: <1375014946.89.0.0130176350727.issue18578@psf.upfronthosting.co.za> Message-ID: <1565206314.36.0.262306512155.issue18578@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- pull_requests: +14900 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15168 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 15:51:19 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 07 Aug 2019 19:51:19 +0000 Subject: [issue24413] Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) returns NotImplemented, but {}.keys().__or__(x) raises TypeError In-Reply-To: <1433827977.01.0.296186023212.issue24413@psf.upfronthosting.co.za> Message-ID: <1565207479.82.0.0380900835422.issue24413@roundup.psfhosted.org> Josh Rosenberg added the comment: To be clear, set().__or__(x) returns NotImplemented, it doesn't raise NotImplementedError. I've edited the title to match. One major problem that gets in the way of a fix is that the interface of set and dict views doesn't match, because dict views only provide the interface of collections.abc.Set, and collections.abc.Set *only* requires the operator overloads, not the named equivalent methods. And because the named equivalents don't exist, the operator overloads were made more liberal, to accept any iterable, not just set or set-like things. set's rules are: 1. Named methods take varargs, and accept any iterable(s) 2. Operator overloads take only one argument, which must be a set/frozenset dict view's rules are: 1. There are no named methods (aside from isdisjoint, which has no operator equivalent) 2. Operator overloads take only one argument, which can be any iterable So fixing this is problematic so long as we want to keep a simple implementation; right now, all the methods simplify to: 1. Convert to set 2. Call named, in-place method on resulting set to get liberal behavior Fixing this would involve either: 1. Rewriting all the dict views operator overloads to do the work themselves, including the logic to reject non-iterables by returning NotImplemented like set's operators do. Pro: Not a hack. Resulting code would be more efficient in many cases (e.g. dict view's __and__ could make a new empty set [currently makes set with a copy of the view's values], and iterate the right hand side while performing membership tests in the underlying dict before inserting into the result set, avoiding the need to make a large set that will almost certainly shrink, possibly requiring rehashes) Con: Lots of new code to maintain. Would not benefit from any algorithmic improvements to equivalent set code without mirroring them manually. 2. Checking for TypeError from the set method and explicitly returning NotImplemented. Pro: Easy, code remains maintainable, benefits from any future optimizations to set Cons: Can't distinguish fundamental problems that should be TypeErrors (right hand side contains unhashable objects) from simple case that should return NotImplemented (right hand side isn't iterable). Potentially fixable by explicitly performing the conversion to iterator on the dict view's side (though you'd only do it to confirm it's possible; you'd want to pass the original object unmodified for the common case where it's a set/frozenset and could be processed more efficiently). Also makes failure case even slower than it already is (exception is raised, then ignored, then NotImplemented is returned, then right-hand side is checked, and odds are, the right-hand side won't know what to do either, so it'll return NotImplemented anyway, and a TypeError gets thrown after more work). 3. Refactor the set API to expose (private, C level) helpers for the operator overloads (specifically, the *in-place* versions like __ior__, since we're always making a new true set to call it on anyway, and it seems silly to use __or__ which would make yet another set, and force us to throw away the first set we made) that are less strict about their arguments. Pros: Roughly the same as #2, plus a minor per-call (not per item) performance boost: C helpers could be called directly, avoiding overhead of calling Python level methods via _PyObject_CallMethodIdOneArg(result, &PyId_update, other); invoking dict lookups and the like when we know we just made a true set object, so there is no possibility of update being overridden, so a direct C level call would save time. Continues to benefit from any optimizations to set's code (since 95% of the code remains the same). Con: More code churn than #2; unfortunately, unlike list (which has type loose in-place operator overloads), set's in-place operator overloads are still type strict; alist += {1,2,3} works, but aset |= [1,2,3] does not, so we can't just call set's __ixor__ unmodified, we'd need a _PySet_IXorIterable separate from the existing set_ior, where both of them might be implemented in terms of set_update_internal, but _PySet_IXorIterable only checks that the argument is iterable to return NotImplemented. #1 and #3 seem to be the only fully correct options; #1 could squeeze out more performance, but requires a *lot* more new code, #3 requires a lot less new code, and gets a tiny performance boost. I don't see explicit calls to __or__ being all that common though, and I have a hard time envisioning a class that would hit this case without explicitly calling __or__; for `{}.keys() | x` the only time you'd see a behavioral difference from `set() | x` is when: 1. x is not iterable, and 2. x defines a __ror__ that can do something meaningful with a set I'd personally assume anything that meets criterion #2 would be iterable; anyone have a counter-example? If this is only a theoretical problem, might it make sense to just leave it as is? ---------- nosy: +josh.r title: Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) raises NotImplementedError, but {}.keys().__or__(x) raises TypeError -> Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) returns NotImplemented, but {}.keys().__or__(x) raises TypeError _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 15:56:31 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 07 Aug 2019 19:56:31 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565207791.4.0.423282241419.issue37774@roundup.psfhosted.org> Change by Josh Rosenberg : ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 16:03:59 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 07 Aug 2019 20:03:59 +0000 Subject: [issue24413] Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) returns NotImplemented, but {}.keys().__or__(x) raises TypeError In-Reply-To: <1433827977.01.0.296186023212.issue24413@psf.upfronthosting.co.za> Message-ID: <1565208239.79.0.195872052303.issue24413@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- assignee: -> rhettinger versions: +Python 3.9 -Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 16:04:24 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 07 Aug 2019 20:04:24 +0000 Subject: [issue24413] Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) returns NotImplemented, but {}.keys().__or__(x) raises TypeError In-Reply-To: <1433827977.01.0.296186023212.issue24413@psf.upfronthosting.co.za> Message-ID: <1565208264.36.0.469886664803.issue24413@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- nosy: -pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 16:05:24 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 07 Aug 2019 20:05:24 +0000 Subject: [issue21762] update the import machinery to only use __spec__ In-Reply-To: <1402781631.86.0.838758150876.issue21762@psf.upfronthosting.co.za> Message-ID: <1565208324.48.0.0656369655462.issue21762@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 16:28:29 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 07 Aug 2019 20:28:29 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565209709.22.0.206635730882.issue37764@roundup.psfhosted.org> Ashwin Ramaswami added the comment: I can't reproduce this on 3.9: https://github.com/epicfaace/cpython/runs/187997615 ---------- nosy: +epicfaace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 16:33:25 2019 From: report at bugs.python.org (Tal Einat) Date: Wed, 07 Aug 2019 20:33:25 +0000 Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys In-Reply-To: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za> Message-ID: <1565210005.31.0.760110005839.issue21261@roundup.psfhosted.org> Change by Tal Einat : ---------- pull_requests: +14901 pull_request: https://github.com/python/cpython/pull/15169 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 16:36:00 2019 From: report at bugs.python.org (Alexander Pyhalov) Date: Wed, 07 Aug 2019 20:36:00 +0000 Subject: [issue37790] subprocess.Popen() is extremely slow Message-ID: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org> New submission from Alexander Pyhalov : We've moved illumos-gate wsdiff python tool from Python 2 to Python 3. The tool does the following - for each file from old and new proto area compares file attributes to find differences in binary otput (spawning elfdump, dump and other utilities). Performance has degraded in two times when commands.getstatusoutput() was replaced by subprocess.getstatusoutput(). os.popen() now is Popen() wrapper, so it also has poor performance. Even naive popen() implementation using os.system() and os.mkstemp() behaved much more efficiently (about two times faster e.g. 20 minuts vs 40 minutes for single tool pass). ---------- components: Library (Lib) messages: 349197 nosy: Alexander.Pyhalov priority: normal severity: normal status: open title: subprocess.Popen() is extremely slow versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 16:36:24 2019 From: report at bugs.python.org (Tal Einat) Date: Wed, 07 Aug 2019 20:36:24 +0000 Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys In-Reply-To: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za> Message-ID: <1565210184.98.0.682669493081.issue21261@roundup.psfhosted.org> Tal Einat added the comment: Raymond, your with may just come true! I've just created PR GH-15169 with a new implementation of my own, complete with tests. I have not yet thoroughly tested it though, and would like some feedback on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 16:37:06 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 07 Aug 2019 20:37:06 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565210226.02.0.72754820689.issue37764@roundup.psfhosted.org> Ashwin Ramaswami added the comment: I also can't reproduce this on 3.7: https://github.com/epicfaace/cpython/runs/188005822 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 16:51:53 2019 From: report at bugs.python.org (My Tran) Date: Wed, 07 Aug 2019 20:51:53 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565211113.14.0.0804640562504.issue37764@roundup.psfhosted.org> My Tran added the comment: Reproduced on 3.7.4 Looks like this started happening after this commit: https://github.com/python/cpython/commit/dc20fc4311dece19488299a7cd11317ffbe4d3c3#diff-19171ae20182f6759204a3436475ddd1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 17:12:45 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 07 Aug 2019 21:12:45 +0000 Subject: [issue37772] zipfile.Path.iterdir() outputs sub directories many times or not at all In-Reply-To: <1565074650.65.0.762547380277.issue37772@roundup.psfhosted.org> Message-ID: <1565212365.83.0.0521263257893.issue37772@roundup.psfhosted.org> Jason R. Coombs added the comment: Please do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 17:13:53 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Wed, 07 Aug 2019 21:13:53 +0000 Subject: [issue37772] zipfile.Path.iterdir() outputs sub directories many times or not at all In-Reply-To: <1565074650.65.0.762547380277.issue37772@roundup.psfhosted.org> Message-ID: <1565212433.94.0.653419233225.issue37772@roundup.psfhosted.org> Change by Jason R. Coombs : ---------- assignee: -> jaraco _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 18:00:47 2019 From: report at bugs.python.org (My Tran) Date: Wed, 07 Aug 2019 22:00:47 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565215247.55.0.121681628435.issue37764@roundup.psfhosted.org> My Tran added the comment: I looked at the job at https://travis-ci.com/epicfaace/cpython/jobs/223345147 and its running py3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 18:49:26 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Wed, 07 Aug 2019 22:49:26 +0000 Subject: [issue37772] zipfile.Path.iterdir() outputs sub directories many times or not at all In-Reply-To: <1565074650.65.0.762547380277.issue37772@roundup.psfhosted.org> Message-ID: <1565218166.78.0.318224770851.issue37772@roundup.psfhosted.org> Change by Srinivas Nyayapati : ---------- keywords: +patch pull_requests: +14902 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15170 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 19:00:18 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 07 Aug 2019 23:00:18 +0000 Subject: [issue35712] Make NotImplemented unusable in boolean context In-Reply-To: <1547157306.18.0.725390794489.issue35712@roundup.psfhosted.org> Message-ID: <1565218818.06.0.552566464002.issue35712@roundup.psfhosted.org> Josh Rosenberg added the comment: In the docs for my PR, I mention using NotImplemented in a boolean context is deprecated, raising DeprecationWarning, and will raise TypeError in a future version of Python. Serhiy has suggested the end state might be RuntimeWarning instead of TypeError. I'm in favor of it ending up as an error, but not rigid on it. Does anyone else have a strong opinion among the following options? 1. DeprecationWarning, documented as eventual TypeError (current PR) 2. DeprecationWarning, documented as eventual RuntimeWarning 3. Immediate RuntimeWarning, no DeprecationWarning period (since a warning only causes stderr output by default, it doesn't prevent working code from working unless warnings are explicitly configured to become exceptions) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 19:07:30 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 07 Aug 2019 23:07:30 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565219250.59.0.921494962744.issue37774@roundup.psfhosted.org> Josh Rosenberg added the comment: Is the intent to make these macros public? If not, shouldn't they be prefixed with an underscore, like _Py_SIZE_ROUND_DOWN/_Py_SIZE_ROUND_UP in the same header? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 20:08:16 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Thu, 08 Aug 2019 00:08:16 +0000 Subject: [issue37772] zipfile.Path.iterdir() outputs sub directories many times or not at all In-Reply-To: <1565074650.65.0.762547380277.issue37772@roundup.psfhosted.org> Message-ID: <1565222896.37.0.540301092749.issue37772@roundup.psfhosted.org> Srinivas Nyayapati added the comment: I just submitted my PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 20:47:03 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 08 Aug 2019 00:47:03 +0000 Subject: [issue37633] Py_CompileString and PyParser_SimpleParseString not exported in python38.dll In-Reply-To: <1563568606.34.0.923231546212.issue37633@roundup.psfhosted.org> Message-ID: <1565225223.35.0.892509029503.issue37633@roundup.psfhosted.org> Ashwin Ramaswami added the comment: I can take this up. ---------- nosy: +epicfaace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 21:26:09 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 08 Aug 2019 01:26:09 +0000 Subject: [issue37790] subprocess.Popen() is extremely slow In-Reply-To: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org> Message-ID: <1565227569.96.0.690447866083.issue37790@roundup.psfhosted.org> Josh Rosenberg added the comment: Have you tried switching to using Popen itself (or run, which keeps it to one layer of convenience wrapping)? subprocess.getstatusoutput is three layers of wrapping (it calls check_output, which in turn calls run, which in turn calls Popen), and (unlike Python 2) has to decode all the output. run would avoid two layers of wrapping, can optionally receive the raw bytes instead of decoding to str, and avoids needing to wrap the whole thing in a shell (which system, older popen, and getstatusoutput all do). Beyond that, it looks like when 3.8 releases, Popen should get *much* faster if the call meets certain conditions, see https://docs.python.org/3.8/whatsnew/3.8.html#optimizations for details. If you can make your use cases conform to those requirements (e.g. by using shutil.which to determine the absolute paths to your utilities instead of relying on PATH lookup), the speed up should eliminate (or more than eliminate) the performance regression you're seeing (per #35537, on macOS, which got the least benefit, it was still a 1.7x improvement; on other OSes, the multiplier hits 61x or 106x). ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 21:57:24 2019 From: report at bugs.python.org (Inada Naoki) Date: Thu, 08 Aug 2019 01:57:24 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565229444.61.0.189468167473.issue37774@roundup.psfhosted.org> Inada Naoki added the comment: I'm conservative about adding public APIs. But in this case, LIKELY/UNLIKELY macros are battle-tested in the world already. So I think it's safe to make it public. But I'll wait to merge for a week for other core dev's comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 23:46:21 2019 From: report at bugs.python.org (Paul Francis) Date: Thu, 08 Aug 2019 03:46:21 +0000 Subject: [issue37786] Doesn't delete PATH from System Variables (uninstallation) In-Reply-To: <1565187839.39.0.765902255643.issue37786@roundup.psfhosted.org> Message-ID: <1565235981.27.0.244471774436.issue37786@roundup.psfhosted.org> Paul Francis added the comment: This is regarding the GUI uninstall program that is accessedd via Programs & Features (formerly known as Add/Remove Programs) in Control Panel. Sorry I didn't make this clear. That "duplicate" report seems to be for a Command Line method of uninstalling the program. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 7 23:47:36 2019 From: report at bugs.python.org (Paul Francis) Date: Thu, 08 Aug 2019 03:47:36 +0000 Subject: [issue37786] Doesn't delete PATH from System Variables (uninstallation) In-Reply-To: <1565187839.39.0.765902255643.issue37786@roundup.psfhosted.org> Message-ID: <1565236056.97.0.628259934074.issue37786@roundup.psfhosted.org> Change by Paul Francis : ---------- resolution: duplicate -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 00:16:36 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 08 Aug 2019 04:16:36 +0000 Subject: [issue37496] Support annotations in signature strings. In-Reply-To: <1562197526.36.0.0415942737779.issue37496@roundup.psfhosted.org> Message-ID: <1565237796.4.0.0343653280592.issue37496@roundup.psfhosted.org> Guido van Rossum added the comment: > 1. Should I create a new function in the `ast` module that exposes that C function in Python in order to use it in `Lib/inspect.py`? > 2. Would it be better to just re-use the _AST to string_ implementation in `Tools/unparse.py`? I would vote for #1. If it is not up to the task that probably points to a flaw anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 00:18:34 2019 From: report at bugs.python.org (Alexander Pyhalov) Date: Thu, 08 Aug 2019 04:18:34 +0000 Subject: [issue37790] subprocess.Popen() is extremely slow In-Reply-To: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org> Message-ID: <1565237914.22.0.593038184833.issue37790@roundup.psfhosted.org> Alexander Pyhalov added the comment: I've tried to rewrite subporcess.getstatusoutput() usage with subprocess.Popen() and switch to shell=False, it didn't help, so I doubti it getstatusoutput() overhead, it's Popen() issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 00:48:11 2019 From: report at bugs.python.org (Ma Lin) Date: Thu, 08 Aug 2019 04:48:11 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565239691.13.0.901722284573.issue37774@roundup.psfhosted.org> Ma Lin added the comment: How about write a suggestion on when to use them in the comment? For example: > You should use it only in cases when the likeliest branch is > very very very likely, or when the unlikeliest branch is very > very very unlikely. from https://kernelnewbies.org/FAQ/LikelyUnlikely Another discussion about them: https://lwn.net/Articles/420019/ ---------- nosy: +Ma Lin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 00:51:19 2019 From: report at bugs.python.org (Greg Price) Date: Thu, 08 Aug 2019 04:51:19 +0000 Subject: [issue18236] str.isspace should use the Unicode White_Space property In-Reply-To: <1371431190.78.0.117337167573.issue18236@psf.upfronthosting.co.za> Message-ID: <1565239879.0.0.554939329427.issue18236@roundup.psfhosted.org> Greg Price added the comment: I've gone and made a patch for this change: https://github.com/gnprice/cpython/commit/7dab9d879 Most of the work happens in the script Tools/unicode/makeunicode.py , and along the way I made several changes there that I found made it somewhat nicer to work on, and I think will help other people reading that script too. So I'd like to try to merge those improvements first. I've filed #37760 for those preparatory changes, and posted several PRs (GH-15128, GH-15129, GH-15130) as bite-sized pieces. These PRs can go in in any order. Please take a look! Reviews appreciated. ---------- nosy: +Greg Price versions: +Python 3.9 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 00:54:07 2019 From: report at bugs.python.org (Greg Price) Date: Thu, 08 Aug 2019 04:54:07 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565240047.57.0.931687240587.issue37760@roundup.psfhosted.org> Change by Greg Price : ---------- pull_requests: +14903 pull_request: https://github.com/python/cpython/pull/15171 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 01:16:40 2019 From: report at bugs.python.org (Ma Lin) Date: Thu, 08 Aug 2019 05:16:40 +0000 Subject: [issue18236] str.isspace should use the Unicode White_Space property In-Reply-To: <1371431190.78.0.117337167573.issue18236@psf.upfronthosting.co.za> Message-ID: <1565241400.55.0.335172887227.issue18236@roundup.psfhosted.org> Ma Lin added the comment: Greg, could you try this code after your patch? >>> import re >>> re.match(r'\s', '\x1e') # <- before patch ---------- nosy: +Ma Lin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 01:17:54 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 08 Aug 2019 05:17:54 +0000 Subject: [issue35712] Make NotImplemented unusable in boolean context In-Reply-To: <1547157306.18.0.725390794489.issue35712@roundup.psfhosted.org> Message-ID: <1565241474.34.0.813434136013.issue35712@roundup.psfhosted.org> Serhiy Storchaka added the comment: I do not have a strong opinion, so I suggest to not mention neither TypeError, nor RuntimeWarning. After some time of using a DeprecationWarning we can have have some information about whether there is a code which can't be fixed if bool(NotImplemented) will raise an error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 01:25:21 2019 From: report at bugs.python.org (Kyle Stanley) Date: Thu, 08 Aug 2019 05:25:21 +0000 Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys In-Reply-To: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za> Message-ID: <1565241921.39.0.691863412602.issue21261@roundup.psfhosted.org> Kyle Stanley added the comment: > I have not yet thoroughly tested it though, and would like some feedback on it. I performed some testing on Linux and it looks good as far as I can tell. I added a few minor suggestions, but the auto-complete seems to be functioning as desired. ---------- nosy: +aeros167 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 01:41:18 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 08 Aug 2019 05:41:18 +0000 Subject: [issue34775] pathlib.PurePath division raises TypeError instead of returning NotImplemented In-Reply-To: <1537686128.89.0.956365154283.issue34775@psf.upfronthosting.co.za> Message-ID: <1565242878.44.0.264065752808.issue34775@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 4c69be22df3852f17873a74d015528d9a8ae92d6 by Serhiy Storchaka (aiudirog) in branch 'master': bpo-34775: Return NotImplemented in PurePath division. (GH-9509) https://github.com/python/cpython/commit/4c69be22df3852f17873a74d015528d9a8ae92d6 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 01:42:57 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 08 Aug 2019 05:42:57 +0000 Subject: [issue37685] Fix equality checks for some types In-Reply-To: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org> Message-ID: <1565242977.78.0.67077548693.issue37685@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 662db125cddbca1db68116c547c290eb3943d98e by Serhiy Storchaka in branch 'master': bpo-37685: Fixed __eq__, __lt__ etc implementations in some classes. (GH-14952) https://github.com/python/cpython/commit/662db125cddbca1db68116c547c290eb3943d98e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 01:43:21 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 08 Aug 2019 05:43:21 +0000 Subject: [issue37685] Fix equality checks for some types In-Reply-To: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org> Message-ID: <1565243001.94.0.377932579816.issue37685@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 7d44e7a4563072d0fad00427b76b94cad61c38ae by Serhiy Storchaka in branch 'master': bpo-37685: Use singletons ALWAYS_EQ and NEVER_EQ in more tests. (GH-15167) https://github.com/python/cpython/commit/7d44e7a4563072d0fad00427b76b94cad61c38ae ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 01:44:33 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 08 Aug 2019 05:44:33 +0000 Subject: [issue34775] pathlib.PurePath division raises TypeError instead of returning NotImplemented In-Reply-To: <1537686128.89.0.956365154283.issue34775@psf.upfronthosting.co.za> Message-ID: <1565243073.56.0.733605773183.issue34775@roundup.psfhosted.org> Change by miss-islington : ---------- keywords: +patch pull_requests: +14904 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/15172 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 01:48:15 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 08 Aug 2019 05:48:15 +0000 Subject: [issue37685] Fix equality checks for some types In-Reply-To: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org> Message-ID: <1565243295.8.0.602655655442.issue37685@roundup.psfhosted.org> Serhiy Storchaka added the comment: ?ukasz, are you fine with backporting PR 14952 to 3.8? ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 02:45:17 2019 From: report at bugs.python.org (Philipp Rauch) Date: Thu, 08 Aug 2019 06:45:17 +0000 Subject: [issue25810] Python 3 documentation for eval is incorrect In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za> Message-ID: <1565246717.6.0.967691406846.issue25810@roundup.psfhosted.org> Change by Philipp Rauch : ---------- versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 02:45:48 2019 From: report at bugs.python.org (Philipp Rauch) Date: Thu, 08 Aug 2019 06:45:48 +0000 Subject: [issue25810] Python 3 documentation for eval is incorrect In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za> Message-ID: <1565246748.74.0.842130176457.issue25810@roundup.psfhosted.org> Change by Philipp Rauch : ---------- versions: +Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 03:06:55 2019 From: report at bugs.python.org (Roundup Robot) Date: Thu, 08 Aug 2019 07:06:55 +0000 Subject: [issue25810] Python 3 documentation for eval is incorrect In-Reply-To: <1449346403.16.0.483198527619.issue25810@psf.upfronthosting.co.za> Message-ID: <1565248015.79.0.489325902817.issue25810@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +14905 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15173 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 03:11:52 2019 From: report at bugs.python.org (Tal Einat) Date: Thu, 08 Aug 2019 07:11:52 +0000 Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys In-Reply-To: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za> Message-ID: <1565248312.51.0.064984894934.issue21261@roundup.psfhosted.org> Tal Einat added the comment: Many thanks for the review, Kyle! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 04:20:45 2019 From: report at bugs.python.org (Marco Sulla) Date: Thu, 08 Aug 2019 08:20:45 +0000 Subject: [issue37791] Propose to deprecate ignore_errors, Message-ID: <1565252445.58.0.903646921674.issue37791@roundup.psfhosted.org> Change by Marco Sulla : ---------- nosy: Marco Sulla priority: normal severity: normal status: open title: Propose to deprecate ignore_errors, _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 04:23:11 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 08 Aug 2019 08:23:11 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1565252591.57.0.379571155388.issue35892@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset e43e7ed36480190083740fd75e2b9cdca72f1a68 by Raymond Hettinger in branch 'master': bpo-35892: Add usage note to mode() (GH-15122) https://github.com/python/cpython/commit/e43e7ed36480190083740fd75e2b9cdca72f1a68 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 04:23:10 2019 From: report at bugs.python.org (Anselm Kruis) Date: Thu, 08 Aug 2019 08:23:10 +0000 Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org> Message-ID: <1565252590.04.0.942616109899.issue37788@roundup.psfhosted.org> Change by Anselm Kruis : ---------- pull_requests: +14906 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15175 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 04:23:23 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 08 Aug 2019 08:23: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: <1565252603.77.0.411213341066.issue35892@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14907 pull_request: https://github.com/python/cpython/pull/15176 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 04:35:36 2019 From: report at bugs.python.org (Marco Sulla) Date: Thu, 08 Aug 2019 08:35:36 +0000 Subject: [issue37791] Propose to deprecate `ignore_errors` and `onerror` parameters of `shutil.rmtree()` Message-ID: <1565253336.61.0.225972441041.issue37791@roundup.psfhosted.org> New submission from Marco Sulla : I propose to mark as deprecated the parameters `ignore_errors` and `onerror` of `shutil.rmtree()`, and raise a warning if used. The reason is I feel them unpythonic. For emulating `ignore_errors=True`, the code can be written simply with a `try-except` that passes by default all `OSError`s . The `ignore_errors=True, onerror=myHandler` case can written simply with a `try-except` that handles `OSError`s. And in the handle can be code or a call to an handler with the same paramaters `myHandler` accept. ---------- components: +Library (Lib) title: Propose to deprecate ignore_errors, -> Propose to deprecate `ignore_errors` and `onerror` parameters of `shutil.rmtree()` type: -> enhancement versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 04:37:00 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 08 Aug 2019 08:37:00 +0000 Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal datasets In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org> Message-ID: <1565253420.71.0.178828973868.issue35892@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 5925b7d555bc36bd43ee8704ae75cc51900cf2d4 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-35892: Add usage note to mode() (GH-15122) (GH-15176) https://github.com/python/cpython/commit/5925b7d555bc36bd43ee8704ae75cc51900cf2d4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 04:45:21 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 08 Aug 2019 08:45:21 +0000 Subject: [issue37791] Propose to deprecate `ignore_errors` and `onerror` parameters of `shutil.rmtree()` In-Reply-To: <1565253336.61.0.225972441041.issue37791@roundup.psfhosted.org> Message-ID: <1565253921.03.0.602638242025.issue37791@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +giampaolo.rodola, serhiy.storchaka, tarek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 04:47:16 2019 From: report at bugs.python.org (Anselm Kruis) Date: Thu, 08 Aug 2019 08:47:16 +0000 Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org> Message-ID: <1565254036.46.0.124559684376.issue37788@roundup.psfhosted.org> Anselm Kruis added the comment: The root cause for the reference leak is the global set threading._shutdown_locks. It contains Thread._tstate_lock locks of non-daemon threads. If a non-daemon thread terminates and no other thread joins the terminated thread, the _tstate_lock remains in threading._shutdown_locks forever. I could imagine that a long running server could accumulate many locks in threading._shutdown_locks over time. Therefore the leak should be fixed. There are probably several ways to deal with this issue. A straight forward approach is to discard the lock from within `tstate->on_delete` hook, that is function "void release_sentinel(void *)" in _threadmodule.c. Pull request (GH-15175) implements this idea. Eventually I should add another C-Python specific test-case to the PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 04:48:42 2019 From: report at bugs.python.org (Anselm Kruis) Date: Thu, 08 Aug 2019 08:48:42 +0000 Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org> Message-ID: <1565254122.54.0.956921613414.issue37788@roundup.psfhosted.org> Change by Anselm Kruis : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 04:57:13 2019 From: report at bugs.python.org (Inada Naoki) Date: Thu, 08 Aug 2019 08:57:13 +0000 Subject: [issue37587] JSON loads performance improvement for long strings In-Reply-To: <1563028922.54.0.821649437171.issue37587@roundup.psfhosted.org> Message-ID: <1565254633.92.0.856192429049.issue37587@roundup.psfhosted.org> Inada Naoki added the comment: New changeset 2a570af12ac5e4ac5575a68f8739b31c24d01367 by Inada Naoki in branch 'master': bpo-37587: optimize json.loads (GH-15134) https://github.com/python/cpython/commit/2a570af12ac5e4ac5575a68f8739b31c24d01367 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 05:24:26 2019 From: report at bugs.python.org (Inada Naoki) Date: Thu, 08 Aug 2019 09:24:26 +0000 Subject: [issue11165] Document PyEval_Call* functions In-Reply-To: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za> Message-ID: <1565256266.76.0.614634773553.issue11165@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 Aug 8 05:25:58 2019 From: report at bugs.python.org (Jakub Kulik) Date: Thu, 08 Aug 2019 09:25:58 +0000 Subject: [issue35484] Segmentation fault due to faulthandler on Solaris In-Reply-To: <1544715488.9.0.788709270274.issue35484@psf.upfronthosting.co.za> Message-ID: <1565256358.96.0.373176397483.issue35484@roundup.psfhosted.org> Jakub Kulik added the comment: Oh, thanks for the catch, it most likely is. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 05:30:16 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 08 Aug 2019 09:30:16 +0000 Subject: [issue37791] Propose to deprecate `ignore_errors` and `onerror` parameters of `shutil.rmtree()` In-Reply-To: <1565253336.61.0.225972441041.issue37791@roundup.psfhosted.org> Message-ID: <1565256616.22.0.989488387103.issue37791@roundup.psfhosted.org> Raymond Hettinger added the comment: I don't see the point of shifting the burden to the caller. That doesn't make their code smaller, clearer, faster, easier to write, or easier to get right. Also, deprecations almost always cause pain so we try to avoid them unless the feature is actually detrimental. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 05:35:36 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 08 Aug 2019 09:35:36 +0000 Subject: [issue37791] Propose to deprecate `ignore_errors` and `onerror` parameters of `shutil.rmtree()` In-Reply-To: <1565253336.61.0.225972441041.issue37791@roundup.psfhosted.org> Message-ID: <1565256936.3.0.112117354681.issue37791@roundup.psfhosted.org> Serhiy Storchaka added the comment: Passing ignore_errors=True is not the same as catching and silencing OSError outside of the function. In the former case you continue removing other files in the directory even if you can't remove some of them. In the latter case you stop after the first failure. onerror gives you even more flexibility. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 05:57:04 2019 From: report at bugs.python.org (Marco Sulla) Date: Thu, 08 Aug 2019 09:57:04 +0000 Subject: [issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity Message-ID: <1565258224.48.0.98423013878.issue37792@roundup.psfhosted.org> New submission from Marco Sulla : Currectly, even if two `Element`s elem1 and elem2 are different objects but the tree is identical, elem1 == elem2 returns False. The only effective way to compare two `Element`s is ElementTree.tostring(elem1) == ElementTree.tostring(elem2) Furthermore, from 3.8 this could be not true anymore, since the order of insertion of attributes will be preserved. So if I simply wrote a tag with two identical attributes, but with different order, the trick will not work anymore. Is it so much complicated to implement an __eq__ for `Element` that traverse its tree? PS: some random remarks about xml.etree.ElementTree module: 1. why `fromstring` and `fromstringlist` separated functions? `fromstring` could use duck typing for the main argument, and `fromstringlist` deprecated. 2. `SubElement`: why the initial is a capital letter? It seems the constructor of a different class, while it's a factory function. I'll change it to `subElement` and deprecate `SubElement` ---------- components: Library (Lib) messages: 349230 nosy: Marco Sulla priority: normal severity: normal status: open title: xml.etree.ElementTree.Element.__eq__ does compare only objects identity versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 06:34:13 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 08 Aug 2019 10:34:13 +0000 Subject: [issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity In-Reply-To: <1565258224.48.0.98423013878.issue37792@roundup.psfhosted.org> Message-ID: <1565260453.72.0.0760305539598.issue37792@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +eli.bendersky, scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 07:01:24 2019 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 08 Aug 2019 11:01:24 +0000 Subject: [issue37791] Propose to deprecate `ignore_errors` and `onerror` parameters of `shutil.rmtree()` In-Reply-To: <1565253336.61.0.225972441041.issue37791@roundup.psfhosted.org> Message-ID: <1565262084.86.0.441488174676.issue37791@roundup.psfhosted.org> Giampaolo Rodola' added the comment: There?s too much code out there relying on both args (especially ignore_errors in unit tests) that would break for no real benefit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 08:36:22 2019 From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgVsOhcmFkeQ==?=) Date: Thu, 08 Aug 2019 12:36:22 +0000 Subject: [issue36753] Python modules not linking to libpython causes issues for RTLD_LOCAL system-wide In-Reply-To: <1556554560.81.0.844742203447.issue36753@roundup.psfhosted.org> Message-ID: <1565267781.99.0.619243340289.issue36753@roundup.psfhosted.org> L?szl? V?rady added the comment: I'd like to mention a real-world example for this issue: syslog-ng with its plugin system. Plugins are loaded using dlopen() after the initial plugin discovery. RTLD_LOCAL would be a reasonable choice, since symbols in plugins should not pollute the global namespace (so plugins using different versions of OpenSSL, Python, etc. would be possible). Since we have Python-based plugins, we had to use RTLD_GLOBAL instead (with RTLD_LAZY to reduce the possibility of conflicts) as a workaround. Note: The latest Python 3 version seems to be working with RTLD_LOCAL as everything under lib-dynload/ linked against libpython. ---------- nosy: +MrAnno _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 09:21:55 2019 From: report at bugs.python.org (Greg Price) Date: Thu, 08 Aug 2019 13:21:55 +0000 Subject: [issue18236] str.isspace should use the Unicode White_Space property In-Reply-To: <1371431190.78.0.117337167573.issue18236@psf.upfronthosting.co.za> Message-ID: <1565270515.73.0.965443590672.issue18236@roundup.psfhosted.org> Greg Price added the comment: Good question! With the patch: >>> import re >>> re.match(r'\s', '\x1e') >>> In other words, the definition of the regexp r'\s' follows along. Good to know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 09:30:55 2019 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 08 Aug 2019 13:30:55 +0000 Subject: [issue37793] argparse uses "container object", should be "iterable" Message-ID: <1565271055.06.0.436207643911.issue37793@roundup.psfhosted.org> New submission from Eric V. Smith : https://docs.python.org/3/library/argparse.html#choices says "These can be handled by passing a container object as the choices keyword argument to add_argument()". I think this should be "iterable" instead. Internally, argparse reads the iterable and converts it to a list so that it can read it multiple times (among other reasons, I'm sure). One of the examples uses range(), which is not a container. "container" is also used in https://docs.python.org/3/library/argparse.html#the-add-argument-method Bonus points for fixing the docstring in argparse.py. I didn't check if anywhere else in that file needs to be fixed. ---------- assignee: docs at python components: Documentation keywords: newcomer friendly messages: 349234 nosy: docs at python, eric.smith priority: normal severity: normal status: open title: argparse uses "container object", should be "iterable" versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 09:59:22 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=) Date: Thu, 08 Aug 2019 13:59:22 +0000 Subject: [issue37779] configparser: add documentation about several read() behaviour In-Reply-To: <1565122960.66.0.217084239893.issue37779@roundup.psfhosted.org> Message-ID: <1565272762.32.0.189956883287.issue37779@roundup.psfhosted.org> Change by St?phane Blondon : ---------- keywords: +patch pull_requests: +14908 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15177 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 10:06:04 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Thu, 08 Aug 2019 14:06:04 +0000 Subject: [issue37793] argparse uses "container object", should be "iterable" In-Reply-To: <1565271055.06.0.436207643911.issue37793@roundup.psfhosted.org> Message-ID: <1565273164.84.0.315873721828.issue37793@roundup.psfhosted.org> Srinivas Nyayapati added the comment: Can I work on this? ---------- nosy: +shireenrao _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 10:15:06 2019 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 08 Aug 2019 14:15:06 +0000 Subject: [issue37793] argparse uses "container object", should be "iterable" In-Reply-To: <1565271055.06.0.436207643911.issue37793@roundup.psfhosted.org> Message-ID: <1565273706.21.0.849243708879.issue37793@roundup.psfhosted.org> Eric V. Smith added the comment: shireenrao: yes, please! As they say, PR's accepted! I'll warn you that I think the only way this could become newcomer-unfriendly is if there are objections that "iterable" is too much jargon for the argparse documentation. But I'll argue that there's a separate tutorial for beginners, and that the documentation should be precise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 10:38:39 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Thu, 08 Aug 2019 14:38:39 +0000 Subject: [issue37793] argparse uses "container object", should be "iterable" In-Reply-To: <1565271055.06.0.436207643911.issue37793@roundup.psfhosted.org> Message-ID: <1565275119.85.0.522382524256.issue37793@roundup.psfhosted.org> Change by Srinivas Nyayapati : ---------- keywords: +patch pull_requests: +14909 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15178 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 10:40:46 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Thu, 08 Aug 2019 14:40:46 +0000 Subject: [issue37793] argparse uses "container object", should be "iterable" In-Reply-To: <1565271055.06.0.436207643911.issue37793@roundup.psfhosted.org> Message-ID: <1565275246.44.0.701673909046.issue37793@roundup.psfhosted.org> Srinivas Nyayapati added the comment: Done. Thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 10:50:59 2019 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 08 Aug 2019 14:50:59 +0000 Subject: [issue37793] argparse uses "container object", should be "iterable" In-Reply-To: <1565271055.06.0.436207643911.issue37793@roundup.psfhosted.org> Message-ID: <1565275859.55.0.976964370726.issue37793@roundup.psfhosted.org> Eric V. Smith added the comment: Actually, I might have mislead you on this. I now think that plain iterators won't work. I'm still researching this, I'll get back to you on it. I apologize if it turns out I wasted your time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 10:56:55 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Thu, 08 Aug 2019 14:56:55 +0000 Subject: [issue37793] argparse uses "container object", should be "iterable" In-Reply-To: <1565271055.06.0.436207643911.issue37793@roundup.psfhosted.org> Message-ID: <1565276215.27.0.0245202496551.issue37793@roundup.psfhosted.org> Srinivas Nyayapati added the comment: Not at all. I just started contributing to cpython 2 days ago and finally got the hang of it and was able to push this without any issues on my side. So either way I would still call this a win for me :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 11:53:23 2019 From: report at bugs.python.org (Andrew Grant) Date: Thu, 08 Aug 2019 15:53:23 +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: <1565279603.0.0.315962296163.issue14465@roundup.psfhosted.org> Change by Andrew Grant : ---------- nosy: +Andrew Grant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 12:20:17 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 08 Aug 2019 16:20:17 +0000 Subject: [issue37786] Doesn't delete PATH from System Variables (uninstallation) In-Reply-To: <1565187839.39.0.765902255643.issue37786@roundup.psfhosted.org> Message-ID: <1565281217.94.0.289129170824.issue37786@roundup.psfhosted.org> Steve Dower added the comment: There's no difference in the implementation between them, so unless you see that the command line approach works but the GUI does not, they are going to be exactly the same bug (and probably against either Windows or Wix, rather than CPython, but I haven't dug deep enough to be sure). ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 12:35:54 2019 From: report at bugs.python.org (Vidar Fauske) Date: Thu, 08 Aug 2019 16:35:54 +0000 Subject: [issue31226] shutil.rmtree fails when target has an internal directory junction (Windows) In-Reply-To: <1502978298.87.0.60982184572.issue31226@psf.upfronthosting.co.za> Message-ID: <1565282154.24.0.149683057039.issue31226@roundup.psfhosted.org> Vidar Fauske added the comment: Thanks for the detailed explanation Eryk. While it is a little annoying that it comes 2 years after the initial proposed solution, I'll happily take that if the end result is a better fix :) That being said, this fix seems quite a bit more involved to implement than the previous one. While I am now slightly more experienced in contributing to Python than previously, I'm not sure if I can commit to implementing the outlined changes without some help. Some things that would help out a lot: - An extracted checklist from the rather longer comment? - Writing up the requirements as tests cases so that I can do test-driven development (I'm not very familiar with the testing suite). If somebody else would want to either do it themselves, or help out with certain parts, I'd be very open to that (I'm not trying to "own" this). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 12:43:03 2019 From: report at bugs.python.org (Christopher Brousseau) Date: Thu, 08 Aug 2019 16:43:03 +0000 Subject: [issue37745] 3.8b3 - windows install gui/ inconsistent options In-Reply-To: <1564766468.14.0.320547199271.issue37745@roundup.psfhosted.org> Message-ID: <1565282583.3.0.779849719717.issue37745@roundup.psfhosted.org> Christopher Brousseau added the comment: First, I'd like to say **thank you** all the work you and the team here do for Python, and Python on Windows. I really appreciate the thoughtful feedback on these ideas. Following up on items in this thread: > do you mean we change "Install launcher for all users" to "Install py launcher for all users"? yes - that is correct, good clarification > long term comments I see - okay, perhaps we should defer this point to think about it in context of a PR (per below). I really like the idea of not requiring complicated leaps of understanding for every type of user. The main idea I'm thinking about on this first screen: the Default and Customize options are complete/self contained actions - but there there are more choices below that could apply to either Default or Customized installations. When a user clicks on Install Now, the installation starts immediately, so the user may not configure these two checkboxes. The Customize workflow allows the user to back out all the way to the first screen, so it's easy for a user to back up to the beginning if they want to. Maybe this is an order of operations question. Perhaps the checkboxes should be above Install Now or Customize, so there is a linear flow of decisions: configure, then execute. Another idea, using UAC perhaps the Default could be 'install py launcher for all users' and not add to PATH. However, it seems like there may be a few additional requirements. One requirement being Default users need the ability optionally install for all users because of Admin privilege issues, secondly the ability to add Python to PATH. A third requirement is these two choices be available and obvious to both installation paths. Are these correct? > test for admin privileges I did not know that testing for this was not possible - learned something - thanks! >To clarify, we add an "Install py launcher for all users" checkbox on screen 3 and remove it from screen 2? What gets removed from screen 3 to make space for it? Correct - that wording seems right. On the space question, it seems like there is space below "Download Debug binaries" so the list from "Associate files" through "Download Debug binaries" could be shifted down without requiring anything to be deleted. > 1. changing current "py launcher" checkbox to "upgrade py launcher" > But this is incorrect. If you don't select the checkbox, you don't get the launcher. It's a choice to have > or not-have, not a choice to upgrade or not-upgrade. Got it - I was responding to the grey text below the current checkbox that reads "Upgrades the global py launcher from the previous version". Would it be correct to label this checkbox as "install py launcher"? > other suggestions discussed in this thread. > e.g. 2. moving "for all users" to next line down - looks like we have space, etc. > This is feasible, but not high priority. PRs welcome. Agree - this is low priority. I will look into doing PR for this, and have to get setup to submit patches etc. so perhaps this is for future release if PR accepted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 13:14:02 2019 From: report at bugs.python.org (Nikita Kniazev) Date: Thu, 08 Aug 2019 17:14:02 +0000 Subject: [issue37794] Replace /Ox with /O2 Message-ID: <1565284442.44.0.244166862045.issue37794@roundup.psfhosted.org> New submission from Nikita Kniazev : The /O2 is a superset of /Ox with additional /GF and /Gy switches which enables strings and functions deduplication and almost always are favorable optimizations without downsides. https://docs.microsoft.com/en-us/cpp/build/reference/ox-full-optimization ---------- components: Distutils messages: 349243 nosy: Kojoley, dstufft, eric.araujo priority: normal severity: normal status: open title: Replace /Ox with /O2 type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 13:14:44 2019 From: report at bugs.python.org (Nikita Kniazev) Date: Thu, 08 Aug 2019 17:14:44 +0000 Subject: [issue37794] Replace /Ox with /O2 In-Reply-To: <1565284442.44.0.244166862045.issue37794@roundup.psfhosted.org> Message-ID: <1565284484.29.0.71667192231.issue37794@roundup.psfhosted.org> Change by Nikita Kniazev : ---------- keywords: +patch pull_requests: +14910 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15179 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 14:01:14 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Thu, 08 Aug 2019 18:01:14 +0000 Subject: [issue36266] Which module could not be found? In-Reply-To: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org> Message-ID: <1565287274.89.0.487609279146.issue36266@roundup.psfhosted.org> Change by Srinivas Nyayapati : ---------- keywords: +patch pull_requests: +14912 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/15180 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 14:03:30 2019 From: report at bugs.python.org (Paul Monson) Date: Thu, 08 Aug 2019 18:03:30 +0000 Subject: [issue36511] Add Windows ARM32 buildbot In-Reply-To: <1554232161.58.0.393661272603.issue36511@roundup.psfhosted.org> Message-ID: <1565287410.38.0.462042232248.issue36511@roundup.psfhosted.org> Change by Paul Monson : ---------- pull_requests: +14913 pull_request: https://github.com/python/cpython/pull/15181 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 14:07:11 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Thu, 08 Aug 2019 18:07:11 +0000 Subject: [issue36266] Which module could not be found? In-Reply-To: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org> Message-ID: <1565287631.26.0.911526830927.issue36266@roundup.psfhosted.org> Srinivas Nyayapati added the comment: I just submitted a PR for this issue. ---------- nosy: +shireenrao _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 14:31:06 2019 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 08 Aug 2019 18:31:06 +0000 Subject: [issue37793] argparse uses "container object", should be "iterable" In-Reply-To: <1565271055.06.0.436207643911.issue37793@roundup.psfhosted.org> Message-ID: <1565289066.41.0.824127261454.issue37793@roundup.psfhosted.org> Eric V. Smith added the comment: Sorry, shireenrao, but I'm closing this. It's entirely my error: I misread the source where it was converting this to a list. The requirement is really that it be something you can iterate over multiple times, and supports "in". I guess "container object" is as good as anything for that. Again, sorry to waste your time, but I'm glad you got something out of the experience. If you're working on another issue and need some help or a review, please let me know. Can you close your PR, or do you want me to? ---------- nosy: -docs at python resolution: -> not a bug stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 14:34:00 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 08 Aug 2019 18:34:00 +0000 Subject: [issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity In-Reply-To: <1565258224.48.0.98423013878.issue37792@roundup.psfhosted.org> Message-ID: <1565289240.4.0.912290245245.issue37792@roundup.psfhosted.org> Raymond Hettinger added the comment: By default, all objects compare based solely on identity. Are you making a feature request for Element objects to grow a recursive equality test that includes attributes regardless of order and disregards processing instructions and comments? What is you principal use case? ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 14:50:09 2019 From: report at bugs.python.org (Christoph Zwerschke) Date: Thu, 08 Aug 2019 18:50:09 +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: <1565290209.71.0.0153112903129.issue27777@roundup.psfhosted.org> Change by Christoph Zwerschke : ---------- nosy: +cito _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 14:50:16 2019 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=) Date: Thu, 08 Aug 2019 18:50:16 +0000 Subject: [issue37779] configparser: add documentation about several read() behaviour In-Reply-To: <1565122960.66.0.217084239893.issue37779@roundup.psfhosted.org> Message-ID: <1565290216.25.0.265404605905.issue37779@roundup.psfhosted.org> St?phane Blondon added the comment: Thank you for the idea. :) I committed something else, based on the previous example of the 'Quick Start' section. What do you think about it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 14:51:04 2019 From: report at bugs.python.org (Jarek Zgoda) Date: Thu, 08 Aug 2019 18:51:04 +0000 Subject: [issue37544] Test hang causes --enable-optimizations build to hang In-Reply-To: <1562757478.69.0.905991720528.issue37544@roundup.psfhosted.org> Message-ID: <1565290264.64.0.265164806052.issue37544@roundup.psfhosted.org> Jarek Zgoda added the comment: Not really. I tried with limited test list and I keep getting the exact same failure in test_logging, moreover build passes all tests on all other machines we have. I guess this is some weird isolated issue not related to Python at all so I'm closing it as "not a bug". Thank you for your help. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 15:15:03 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Thu, 08 Aug 2019 19:15:03 +0000 Subject: [issue37793] argparse uses "container object", should be "iterable" In-Reply-To: <1565271055.06.0.436207643911.issue37793@roundup.psfhosted.org> Message-ID: <1565291703.19.0.51731656743.issue37793@roundup.psfhosted.org> Srinivas Nyayapati added the comment: I understand eric.smith. I can close this PR. I currently have the following 3 other PR's waiting for review on github - https://github.com/python/cpython/pull/15180 https://github.com/python/cpython/pull/15170 https://github.com/python/cpython/pull/15149 Would appreciate it if you could take a look :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 15:46:27 2019 From: report at bugs.python.org (Richard Musil) Date: Thu, 08 Aug 2019 19:46:27 +0000 Subject: [issue16535] json encoder unable to handle decimal In-Reply-To: <1353624338.46.0.574343718645.issue16535@psf.upfronthosting.co.za> Message-ID: <1565293587.54.0.728245279323.issue16535@roundup.psfhosted.org> Richard Musil added the comment: It looks like I am resurrecting an old item, but I have been just hit by this and was directed to this issue (https://mail.python.org/archives/list/python-ideas at python.org/thread/WT6Z6YJDEZXKQ6OQLGAPB3OZ4OHCTPDU/) I wonder if adding something similar to what `simplejson` uses (i.e. explicitly specifying in `json.dump(s)` how to serialize `decimal.Decimal`) could be acceptable. Or, the other idea would be to expose a method in JSONEncoder, which would accept "raw" textual output, i.e. string (or even `bytes`) and would encode it without adding additional characters to it. (as explained in my posts in the other threads). As it seems right now, there is no way to serialize `decimal.Decimal` the same way it is deserialized, i.e. while preserving the (arbitrary) precision. ---------- nosy: +risa2000 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 16:03:08 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 08 Aug 2019 20:03:08 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565294588.0.0.881363522017.issue25172@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14914 pull_request: https://github.com/python/cpython/pull/15182 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 16:02:58 2019 From: report at bugs.python.org (Paul Moore) Date: Thu, 08 Aug 2019 20:02:58 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565294578.06.0.203093078729.issue25172@roundup.psfhosted.org> Paul Moore added the comment: New changeset f4e725f224b864bf9bf405ff7f863cda46fca1cd by Paul Moore (shireenrao) in branch 'master': bpo-25172: Raise appropriate ImportError msg when crypt module used on Windows (GH-15149) https://github.com/python/cpython/commit/f4e725f224b864bf9bf405ff7f863cda46fca1cd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 16:07:14 2019 From: report at bugs.python.org (Paul Moore) Date: Thu, 08 Aug 2019 20:07:14 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565294834.26.0.186291260933.issue25172@roundup.psfhosted.org> Paul Moore added the comment: On reflection, adding a test for the Windows-specific behaviour looks like it could be more complex than I'd anticipated, so I'm happy for this to go in without an extra test. I'll look at adding a test in a follow-up PR (or if someone else wants to, that's fine as well). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 16:31:24 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Thu, 08 Aug 2019 20:31:24 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565296284.32.0.930858549473.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: I am curious how one would create a test for this? Would this be a new test script? The new script would skip if platform not win32 and the test case would be to import the crypt module and check for "not supported" string in the ImportError? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 17:07:55 2019 From: report at bugs.python.org (Paul Moore) Date: Thu, 08 Aug 2019 21:07:55 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565298475.89.0.97357555618.issue25172@roundup.psfhosted.org> Paul Moore added the comment: That's where I decided it was too complex for now :-) The whole test_crypt.py file is skipped if you can't import crypt, via the use of the test.support.import_module() function. To be able to write a test for a platform where the whole point is that you can't import crypt, you'd have to rewrite that. So you'd get something like try: import crypt except ImportError as e: if sys.platform == "win32": assert "not supported" in e.msg raise unittest.SkipTest("crypt is not present on this platform") But you can't use "assert" like that in top-level code (or at least I don't think you can - I'm not that familiar with unittest, but I think assertions have to live in classes in unittest). At this point I gave up. It starts to be quite a big rewrite for a relatively minor benefit. The alternative would be, if there was a "Windows-specific tests" test module, we could have put a test for this situation in there. But I don't think there is such a module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 17:11:08 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 08 Aug 2019 21:11:08 +0000 Subject: [issue36753] Python modules not linking to libpython causes issues for RTLD_LOCAL system-wide In-Reply-To: <1556554560.81.0.844742203447.issue36753@roundup.psfhosted.org> Message-ID: <1565298668.08.0.510512061394.issue36753@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: In the What's New section of 3.8 (https://docs.python.org/3.8/whatsnew/3.8.html#changes-in-the-c-api) it indicates that: > On Unix, C extensions are no longer linked to libpython except on Android and Cygwin. When Python is embedded, libpython must not be loaded with RTLD_LOCAL, but RTLD_GLOBAL instead. Previously, using RTLD_LOCAL, it was already not possible to load C extensions which were not linked to libpython, like C extensions of the standard library built by the *shared* section of Modules/Setup. (Contributed by Victor Stinner in bpo-21536.) So if you are embedding python by dlopen'ing libpython.so you should use RTLD_GLOBAL to make sure everyone is using the same symbols. You have more information on the rationale and decisions in bpo-21536. Is your use-case not cover by the arguments in bpo-21536? What is the problem of embedding by dlopening libpython using RTLD_GLOBAL? ---------- nosy: +pablogsal versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 17:11:50 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 08 Aug 2019 21:11:50 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565298710.25.0.647518349603.issue25172@roundup.psfhosted.org> Steve Dower added the comment: > The alternative would be, if there was a "Windows-specific tests" test module, we could have put a test for this situation in there Maybe test___all__? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 17:16:08 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 08 Aug 2019 21:16:08 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565298968.73.0.354930232573.issue25172@roundup.psfhosted.org> Steve Dower added the comment: Or better yet (since my last suggestion was bad), add a second test class to test_crypt try: import crypt IMPORT_ERROR = None except ImportError as ex: crypt = None IMPORT_ERROR = str(ex) @skipIf(crypt) class TestWhyCryptDidNotImport(TestCase): ... @skipUnless(crypt) class CryptTestCase(TestCase): ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 17:29:45 2019 From: report at bugs.python.org (Zackery Spytz) Date: Thu, 08 Aug 2019 21:29:45 +0000 Subject: [issue37268] Deprecate the parser module In-Reply-To: <1560427899.74.0.436857498848.issue37268@roundup.psfhosted.org> Message-ID: <1565299785.56.0.603031867492.issue37268@roundup.psfhosted.org> Change by Zackery Spytz : ---------- pull_requests: +14915 pull_request: https://github.com/python/cpython/pull/15183 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 17:33:12 2019 From: report at bugs.python.org (Philip Dye) Date: Thu, 08 Aug 2019 21:33:12 +0000 Subject: [issue37636] Deprecate slicing and ordering operations on sys.version In-Reply-To: <1563626755.13.0.11799518747.issue37636@roundup.psfhosted.org> Message-ID: <1565299992.55.0.594601638639.issue37636@roundup.psfhosted.org> Change by Philip Dye : ---------- nosy: +Philip Dye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 17:36:40 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Thu, 08 Aug 2019 21:36:40 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565300200.76.0.982672446597.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: Are you suggesting using the try/except block instead of import_module in test_crypt.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 17:38:29 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 08 Aug 2019 21:38:29 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565300309.51.0.73303413764.issue25172@roundup.psfhosted.org> Steve Dower added the comment: Yes. support.import_module is going to raise a skip when the module can't be imported, but we want to handle ImportError differently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 17:48:04 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 08 Aug 2019 21:48:04 +0000 Subject: [issue37268] Deprecate the parser module In-Reply-To: <1560427899.74.0.436857498848.issue37268@roundup.psfhosted.org> Message-ID: <1565300884.76.0.44432340159.issue37268@roundup.psfhosted.org> miss-islington added the comment: New changeset 10a0a093231ea82a3bfd33fd63322aebd8406866 by Miss Islington (bot) (Zackery Spytz) in branch 'master': bpo-37268: test_parser fails when run with -Werror (GH-15183) https://github.com/python/cpython/commit/10a0a093231ea82a3bfd33fd63322aebd8406866 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 17:57:48 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 08 Aug 2019 21:57:48 +0000 Subject: [issue37795] Fix deprecation warnings causing the test suite to fail when running with -Werror Message-ID: <1565301468.37.0.920953443916.issue37795@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : The test suite is failing when running with python -Werror due to some uncatched DeprecationWarnings. ---------- components: Tests messages: 349261 nosy: pablogsal priority: normal severity: normal status: open title: Fix deprecation warnings causing the test suite to fail when running with -Werror versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 17:58:42 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 08 Aug 2019 21:58:42 +0000 Subject: [issue37795] Fix deprecation warnings causing the test suite to fail when running with -Werror In-Reply-To: <1565301468.37.0.920953443916.issue37795@roundup.psfhosted.org> Message-ID: <1565301522.07.0.0484925998067.issue37795@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +14916 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15184 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 18:00:26 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Thu, 08 Aug 2019 22:00:26 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565301626.04.0.539895785588.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: Can I have a go at it? Do I need to open a new issue to post a new PR? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 18:25:49 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 08 Aug 2019 22:25:49 +0000 Subject: [issue37795] Fix deprecation warnings causing the test suite to fail when running with -Werror In-Reply-To: <1565301468.37.0.920953443916.issue37795@roundup.psfhosted.org> Message-ID: <1565303149.11.0.477688840929.issue37795@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: New changeset aa542c2cf26c5af9298dda6064576b18906cdfbf by Pablo Galindo in branch 'master': bpo-37795: Capture DeprecationWarnings in the test suite (GH-15184) https://github.com/python/cpython/commit/aa542c2cf26c5af9298dda6064576b18906cdfbf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 18:25:50 2019 From: report at bugs.python.org (Christoph Zwerschke) Date: Thu, 08 Aug 2019 22:25:50 +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: <1565303150.27.0.438016361122.issue27777@roundup.psfhosted.org> Christoph Zwerschke added the comment: This also happens when sending POST requests with JSON payload from a browser with XMLHttpRequest to a Python 3.7 backend using FieldStorage. It seems XMLHttpRequest adds the content length automatically. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 18:25:58 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 08 Aug 2019 22:25:58 +0000 Subject: [issue37795] Fix deprecation warnings causing the test suite to fail when running with -Werror In-Reply-To: <1565301468.37.0.920953443916.issue37795@roundup.psfhosted.org> Message-ID: <1565303158.81.0.419667130434.issue37795@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14917 pull_request: https://github.com/python/cpython/pull/15185 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 18:26:17 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 08 Aug 2019 22:26:17 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565303177.52.0.322106721884.issue25172@roundup.psfhosted.org> Steve Dower added the comment: Sure. You can post a new PR with the same bug number (and it won't need a NEWS file this time). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 18:30:11 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 08 Aug 2019 22:30:11 +0000 Subject: [issue37795] Fix deprecation warnings causing the test suite to fail when running with -Werror In-Reply-To: <1565301468.37.0.920953443916.issue37795@roundup.psfhosted.org> Message-ID: <1565303411.97.0.0569076225269.issue37795@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 Aug 8 18:49:20 2019 From: report at bugs.python.org (George Zhang) Date: Thu, 08 Aug 2019 22:49:20 +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: <1565304560.0.0.250611931116.issue32810@roundup.psfhosted.org> George Zhang added the comment: Also, while the PEP first introducing asynchronous generators stated that its .asend() and .athrow() methods will return a "coroutine-like object", it doesn't allow any introspection into its state or parent async generator. My workaround was to wrap the .asend() and other methods with another coroutine that just awaits and returns the result. Having a better way to check its state and frame will bring it closer to a coroutine. ---------- nosy: +GeeVye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 19:12:37 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 08 Aug 2019 23:12:37 +0000 Subject: [issue36511] Add Windows ARM32 buildbot In-Reply-To: <1554232161.58.0.393661272603.issue36511@roundup.psfhosted.org> Message-ID: <1565305956.99.0.442990260827.issue36511@roundup.psfhosted.org> Steve Dower added the comment: New changeset ed70a344b5fbddea85726ebc1964ee0cfdef9c40 by Steve Dower (Paul Monson) in branch 'master': bpo-36511: Fix failures in Windows ARM32 buildbot (GH-15181) https://github.com/python/cpython/commit/ed70a344b5fbddea85726ebc1964ee0cfdef9c40 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 19:13:06 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 08 Aug 2019 23:13:06 +0000 Subject: [issue36511] Add Windows ARM32 buildbot In-Reply-To: <1554232161.58.0.393661272603.issue36511@roundup.psfhosted.org> Message-ID: <1565305986.09.0.659552279142.issue36511@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14918 pull_request: https://github.com/python/cpython/pull/15186 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 19:30:55 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 08 Aug 2019 23:30:55 +0000 Subject: [issue37795] Fix deprecation warnings causing the test suite to fail when running with -Werror In-Reply-To: <1565301468.37.0.920953443916.issue37795@roundup.psfhosted.org> Message-ID: <1565307055.56.0.237038628044.issue37795@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14919 pull_request: https://github.com/python/cpython/pull/15187 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 19:44:29 2019 From: report at bugs.python.org (Philip Dye) Date: Thu, 08 Aug 2019 23:44:29 +0000 Subject: [issue21861] io class name are hardcoded in reprs In-Reply-To: <1403631418.74.0.109096243494.issue21861@psf.upfronthosting.co.za> Message-ID: <1565307869.48.0.79540468975.issue21861@roundup.psfhosted.org> Change by Philip Dye : ---------- nosy: +Philip Dye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 19:58:05 2019 From: report at bugs.python.org (Philip Dye) Date: Thu, 08 Aug 2019 23:58:05 +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: <1565308685.88.0.862159021264.issue18697@roundup.psfhosted.org> Change by Philip Dye : ---------- nosy: +Philip Dye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 20:01:42 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 09 Aug 2019 00:01:42 +0000 Subject: [issue37795] Fix deprecation warnings causing the test suite to fail when running with -Werror In-Reply-To: <1565301468.37.0.920953443916.issue37795@roundup.psfhosted.org> Message-ID: <1565308902.69.0.382382894537.issue37795@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- pull_requests: +14920 pull_request: https://github.com/python/cpython/pull/15188 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 20:02:55 2019 From: report at bugs.python.org (Michael Kleehammer) Date: Fri, 09 Aug 2019 00:02:55 +0000 Subject: [issue37796] ModuleFinder does not resolve ".." correctly Message-ID: <1565308975.62.0.708639838016.issue37796@roundup.psfhosted.org> New submission from Michael Kleehammer : The modulefinder module does not handle relative directories properly. The error I found is when one subpackage attempts to import from a sibling subpackage using the form from ..language import ( DirectiveDefinitionNode, ... ) In this example, it would report "language.DirectiveDefinitionNode" is missing. It correctly resolves the names when importing modules, but when an import fails because it is a variable or function, it records the name incorrectly and cannot filter it out later. I've attached a small test case and there is a README describing the test and results. ---------- components: Library (Lib) files: test.tar.gz messages: 349268 nosy: mkleehammer priority: normal severity: normal status: open title: ModuleFinder does not resolve ".." correctly type: behavior versions: Python 3.7, Python 3.8 Added file: https://bugs.python.org/file48535/test.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 20:23:02 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 09 Aug 2019 00:23:02 +0000 Subject: [issue37795] Fix deprecation warnings causing the test suite to fail when running with -Werror In-Reply-To: <1565301468.37.0.920953443916.issue37795@roundup.psfhosted.org> Message-ID: <1565310182.14.0.565988334029.issue37795@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: New changeset 162d45c531552d0699f945d2c22a763941dca3c1 by Pablo Galindo in branch '3.8': [3.8] bpo-37795: Capture DeprecationWarnings in the test suite (GH-15184) (GH-15188) https://github.com/python/cpython/commit/162d45c531552d0699f945d2c22a763941dca3c1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 20:30:15 2019 From: report at bugs.python.org (skreft) Date: Fri, 09 Aug 2019 00:30:15 +0000 Subject: [issue37797] Add name attribute to NameError Message-ID: <1565310615.1.0.816641824281.issue37797@roundup.psfhosted.org> New submission from skreft : PEP 473 was recently rejected (https://mail.python.org/pipermail/python-dev/2019-March/156692.html) because it was too broad and was suggested to be broken down in smaller issues. This issue is requesting the addition of the optional attribute `name` to `NameError`. The idea of having a structured attribute is to allow tools to act upon these exceptions. For example you could imagine a test runner which detect typos and suggests the right name to use. There is a current PR (https://github.com/python/cpython/pull/6271) adding this functionality, but it may need to be rebased as it has been awaiting a reply since April last year. ---------- components: Interpreter Core messages: 349270 nosy: skreft priority: normal pull_requests: 14921 severity: normal status: open title: Add name attribute to NameError type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 22:38:23 2019 From: report at bugs.python.org (Philip Dye) Date: Fri, 09 Aug 2019 02:38:23 +0000 Subject: [issue23560] Group the docs of similar methods in stdtypes.rst In-Reply-To: <1425288490.4.0.288876913126.issue23560@psf.upfronthosting.co.za> Message-ID: <1565318303.52.0.572815812906.issue23560@roundup.psfhosted.org> Change by Philip Dye : ---------- nosy: +Philip Dye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 22:38:57 2019 From: report at bugs.python.org (Philip Dye) Date: Fri, 09 Aug 2019 02:38:57 +0000 Subject: [issue17301] An in-place version of many bytearray methods is needed In-Reply-To: <1361910523.06.0.491264384267.issue17301@psf.upfronthosting.co.za> Message-ID: <1565318337.66.0.900864396506.issue17301@roundup.psfhosted.org> Change by Philip Dye : ---------- nosy: +Philip Dye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 23:03:03 2019 From: report at bugs.python.org (Philip Dye) Date: Fri, 09 Aug 2019 03:03:03 +0000 Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple api In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za> Message-ID: <1565319783.24.0.106700022521.issue1820@roundup.psfhosted.org> Change by Philip Dye : ---------- nosy: +Philip Dye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 8 23:16:37 2019 From: report at bugs.python.org (Philip Dye) Date: Fri, 09 Aug 2019 03:16:37 +0000 Subject: [issue15436] __sizeof__ is not documented In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za> Message-ID: <1565320597.77.0.347231981828.issue15436@roundup.psfhosted.org> Change by Philip Dye : ---------- nosy: +Philip Dye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 00:33:41 2019 From: report at bugs.python.org (David Wilson) Date: Fri, 09 Aug 2019 04:33:41 +0000 Subject: [issue37696] FileIO.read() on a closed TTY throws an exception prematurely In-Reply-To: <1564325470.84.0.0876609070441.issue37696@roundup.psfhosted.org> Message-ID: <1565325221.78.0.137848530706.issue37696@roundup.psfhosted.org> David Wilson added the comment: Interesting, this immediately turns into a little rabbit hole :) The reason read() is failing in this case, is because argument clinic defaults the size parameter to -1, which redirects the call to readall(). So this issue is actually about readall(). Calling read(8) in the previous reproduction returns the buffer up to the point of EIO as expected. readall() is somewhat awkward. It is not really expected that a user would call it twice, and so the old semantic of the second read() returning EIO doesn't seem to apply cleanly. So >=2 issues: - readall() is discarding the partial buffer, that seems unavoidably like a bug - readall() does not intuitively feel like a function you might want to call twice - nothing in fileio.c or fileutils.c make any attempt to understand errno except for handling EINTR. I'm guessing the 2.x behaviour in this case was that no parsing of errno was done either, just silently discard any error when a partial buffer exists. But that leaves the awkward possibility that some real scary error occurred, for example EBADF or EFAULT, and the single call by the user to readall() never flagged it. Opinions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 00:38:39 2019 From: report at bugs.python.org (David Wilson) Date: Fri, 09 Aug 2019 04:38:39 +0000 Subject: [issue37696] FileIO.read() on a closed TTY throws an exception prematurely In-Reply-To: <1564325470.84.0.0876609070441.issue37696@roundup.psfhosted.org> Message-ID: <1565325519.69.0.0026313674421.issue37696@roundup.psfhosted.org> David Wilson added the comment: If we treat different errnos specially, the list of 'okay to silently fail' errors seems quite succinct. In another project I treat EIO, EPIPE and ECONNRESET as EOF, and raise all others -- https://github.com/dw/mitogen/blob/c6de090f083a58344e91ab97847bf7ae3feb9134/mitogen/core.py#L501-L532 But even in this case, if readall() returns the partial buffer given a 'good' errno, does it still discard the partial buffer given a 'bad' one? That still doesn't feel right ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 00:43:26 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 09 Aug 2019 04:43:26 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() Message-ID: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> New submission from Raymond Hettinger : Create new module: Modules/_statisticsmodule.c Add a function: _normal_dist_inv_cdf(p, mu, sigma) |-> x Mostly, it should be a cut-and-paste from the pure Python version, just add argument processing and semi-colons. Expect to measure a manyfold speedup. ---------- components: Extension Modules keywords: easy (C) messages: 349273 nosy: rhettinger, steven.daprano priority: normal severity: normal status: open title: Add C fastpath for statistics.NormalDist.inv_cdf() versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 00:49:36 2019 From: report at bugs.python.org (David Wilson) Date: Fri, 09 Aug 2019 04:49:36 +0000 Subject: [issue37696] FileIO.read() on a closed TTY throws an exception prematurely In-Reply-To: <1564325470.84.0.0876609070441.issue37696@roundup.psfhosted.org> Message-ID: <1565326176.32.0.833306874384.issue37696@roundup.psfhosted.org> David Wilson added the comment: A real example of where returning the partial buffer is dangerous would be EBADF. - Repeated reading succeeds, building up a partial buffer. Another thread runs, and buggy code causes an unrelated fd blonging to the file object to be closed. - Original thread resumes, calls read(), which now returns EBADF. If partial buffer is returned and EBADF is masked, and user only ever calls readall() once, a potentially deadly IO corruption bug is completely hidden in their code. I think the correct behaviour in the case of 'bad' errno must remain that the partial buffer is discarded, the interface does not seem to make room for any safe+better option So I think to reach the desired outcome of this ticket, the suggested approach is to add special handling for a small list of errnos generally accepted to unambiguously mean EOF, and in that special case, allow returning the 'partial' (actually complete) buffer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 02:08:42 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Fri, 09 Aug 2019 06:08:42 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565330922.39.0.413805978101.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: When I try to put the skipUnless decorator on CryptTestCase, I am still seeing a failure when I try to run this. The error is - File "C:\Users\srao\projects\cpython\lib\test\test_crypt.py", line 59, in CryptTestCase @unittest.skipUnless(crypt.METHOD_SHA256 in crypt.methods or AttributeError: 'NoneType' object has no attribute 'METHOD_SHA256' Line 59 is the following decorator and method - @unittest.skipUnless(crypt.METHOD_SHA256 in crypt.methods or crypt.METHOD_SHA512 in crypt.methods, 'requires support of SHA-2') def test_sha2_rounds(self): I tried a simple @skip decorator and that too fails on the same error. The class level skip is not helping here. Does it make sense to create a different test file for windows? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 03:53:36 2019 From: report at bugs.python.org (Bernhard Hiller) Date: Fri, 09 Aug 2019 07:53:36 +0000 Subject: [issue37762] IDLE very slow due a super long line output in chunks In-Reply-To: <1565014260.07.0.714424226111.issue37762@roundup.psfhosted.org> Message-ID: <1565337216.84.0.656766905036.issue37762@roundup.psfhosted.org> Bernhard Hiller added the comment: Please find enclosed a screen shot of the command line, when the same script is run there. If you want to perform the tests yourself in order to get more information about the type of those characters, you may simply run the script mentioned in my first post. Furthermore, when running the script from the Python command prompt, I see a process called "python.exe" (without "w") in the task manager, taking some 70% of CPU. ---------- Added file: https://bugs.python.org/file48536/Python374-4.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 04:23:24 2019 From: report at bugs.python.org (Abhilash Raj) Date: Fri, 09 Aug 2019 08:23:24 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565339004.26.0.376031497699.issue37764@roundup.psfhosted.org> Abhilash Raj added the comment: This does look like a side-effect of the commit mentioned by mytran. The issues seems to be that email._header_value_parser.get_unstructured wrongfully assumes that anything leading with '=?' would be a valid rfc 2047 encoded word. This is a smaller test case to reproduce this bug: from email._header_value_parser import get_unstructured get_unstructured('=?utf-8?q?FSaiz4vX3XMJPT4vrExGUZeOnp0o22pLBB7CYLH74Js=3DwOlK6Tfru2U47qR?=72OfyEY2p2/rA9xNFyvH+fBTCmazxwzF8nGkK6D') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 04:23:33 2019 From: report at bugs.python.org (Abhilash Raj) Date: Fri, 09 Aug 2019 08:23:33 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565339013.28.0.542704487857.issue37764@roundup.psfhosted.org> Change by Abhilash Raj : ---------- versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 04:29:56 2019 From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=) Date: Fri, 09 Aug 2019 08:29:56 +0000 Subject: [issue35181] Doc: Namespace Packages: Inconsistent documentation of __loader__ being None In-Reply-To: <1541543349.68.0.788709270274.issue35181@psf.upfronthosting.co.za> Message-ID: <1565339396.22.0.450289818089.issue35181@roundup.psfhosted.org> Change by G?ry : ---------- pull_requests: +14922 pull_request: https://github.com/python/cpython/pull/15190 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 04:30:50 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 09 Aug 2019 08:30:50 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1565339450.87.0.519526011275.issue34155@roundup.psfhosted.org> miss-islington added the comment: New changeset c48d606adcef395e59fd555496c42203b01dd3e8 by Miss Islington (bot) in branch '3.7': bpo-34155: Dont parse domains containing @ (GH-13079) https://github.com/python/cpython/commit/c48d606adcef395e59fd555496c42203b01dd3e8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 04:31:33 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 09 Aug 2019 08:31:33 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1565339493.31.0.782131040082.issue34155@roundup.psfhosted.org> miss-islington added the comment: New changeset 217077440a6938a0b428f67cfef6e053c4f8673c by Miss Islington (bot) in branch '3.8': bpo-34155: Dont parse domains containing @ (GH-13079) https://github.com/python/cpython/commit/217077440a6938a0b428f67cfef6e053c4f8673c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 05:38:48 2019 From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=) Date: Fri, 09 Aug 2019 09:38:48 +0000 Subject: [issue37799] Renaming Doc/reference/ to Doc/language/ Message-ID: <1565343528.85.0.0920762754632.issue37799@roundup.psfhosted.org> New submission from G?ry : The page https://docs.python.org/3/ lists these two parts: - Library Reference - Language Reference So both parts are "references". However in the cpython GitHub repository, the Doc/ directory contains these two directories: - library/ - reference/ So to be consistent, shouldn't we rename the Doc/reference/ directory to Doc/language/? ---------- assignee: docs at python components: Documentation messages: 349280 nosy: docs at python, maggyero priority: normal severity: normal status: open title: Renaming Doc/reference/ to Doc/language/ versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 05:39:06 2019 From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=) Date: Fri, 09 Aug 2019 09:39:06 +0000 Subject: [issue37799] Renaming Doc/reference/ to Doc/language/ In-Reply-To: <1565343528.85.0.0920762754632.issue37799@roundup.psfhosted.org> Message-ID: <1565343546.31.0.900810814537.issue37799@roundup.psfhosted.org> Change by G?ry : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 06:11:12 2019 From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=) Date: Fri, 09 Aug 2019 10:11:12 +0000 Subject: [issue37800] Clean up the documentation on module attributes Message-ID: <1565345472.1.0.903395402211.issue37800@roundup.psfhosted.org> Change by G?ry : ---------- assignee: docs at python components: Documentation nosy: docs at python, eric.snow, maggyero priority: normal pull_requests: 14923 severity: normal status: open title: Clean up the documentation on module attributes type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 07:08:52 2019 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 09 Aug 2019 11:08:52 +0000 Subject: [issue36402] threading._shutdown() race condition: test_threading test_threads_join_2() fails randomly In-Reply-To: <1553296704.08.0.921014854557.issue36402@roundup.psfhosted.org> Message-ID: <1565348932.44.0.0758405261426.issue36402@roundup.psfhosted.org> Kristj?n Valur J?nsson added the comment: Please note that this fix appears to be the cause of #37788 ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 07:53:21 2019 From: report at bugs.python.org (Vadim Engelson) Date: Fri, 09 Aug 2019 11:53:21 +0000 Subject: [issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...) Message-ID: <1565351601.24.0.515340331062.issue37801@roundup.psfhosted.org> New submission from Vadim Engelson : Compilation on MINGW64 fails (CODESET,wcstok,...) I am using the latest MINGW64 (http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20190524.exe) Versions: Python-3.7.2, Python-3.8.0b3 $ gcc -v Using built-in specs. COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.1.0/lto-wrapper.exe Target: x86_64-w64-mingw32 gcc version 9.1.0 (Rev3, Built by MSYS2 project) Result of make: Python/initconfig.c: In function 'config_get_locale_encoding': Python/initconfig.c:1427:28: error: implicit declaration of function 'nl_langinfo' [-Werror=implicit-function-declaration] 1427 | const char *encoding = nl_langinfo(CODESET); | ^~~~~~~~~~~ Python/initconfig.c:1427:40: error: 'CODESET' undeclared (first use in this function); did you mean 'ECONNRESET'? 1427 | const char *encoding = nl_langinfo(CODESET); | ^~~~~~~ | ECONNRESET Python/initconfig.c:1427:40: note: each undeclared identifier is reported only once for each function it appears in Python/initconfig.c: In function 'config_init_env_warnoptions': Python/initconfig.c:1992:18: error: too many arguments to function 'wcstok' 1992 | # define WCSTOK wcstok | ^~~~~~ Python/initconfig.c:2015:20: note: in expansion of macro 'WCSTOK' 2015 | for (warning = WCSTOK(env, L",", &context); | ^~~~~~ In file included from ./Include/Python.h:30, from Python/initconfig.c:1: C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:147:20: note: declared here 147 | wchar_t *__cdecl wcstok(wchar_t * __restrict__ _Str,const wchar_t * __restrict__ _Delim) __MINGW_ATTRIB_DEPRECATED_SEC_WARN; | ^~~~~~ Python/initconfig.c:1992:18: error: too many arguments to function 'wcstok' 1992 | # define WCSTOK wcstok | ^~~~~~ Python/initconfig.c:2017:20: note: in expansion of macro 'WCSTOK' 2017 | warning = WCSTOK(NULL, L",", &context)) | ^~~~~~ In file included from ./Include/Python.h:30, from Python/initconfig.c:1: C:/msys64/mingw64/x86_64-w64-mingw32/include/string.h:147:20: note: declared here 147 | wchar_t *__cdecl wcstok(wchar_t * __restrict__ _Str,const wchar_t * __restrict__ _Delim) __MINGW_ATTRIB_DEPRECATED_SEC_WARN; | ^~~~~~ cc1.exe: some warnings being treated as errors make: *** [Makefile:1703: Python/initconfig.o] Error 1 ---------- components: Build, Interpreter Core, Windows messages: 349282 nosy: paul.moore, steve.dower, tim.golden, vengelson, zach.ware priority: normal severity: normal status: open title: Compilation on MINGW64 fails (CODESET,wcstok,...) type: compile error versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 07:54:58 2019 From: report at bugs.python.org (Vadim Engelson) Date: Fri, 09 Aug 2019 11:54:58 +0000 Subject: [issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...) In-Reply-To: <1565351601.24.0.515340331062.issue37801@roundup.psfhosted.org> Message-ID: <1565351698.58.0.818890310879.issue37801@roundup.psfhosted.org> Vadim Engelson added the comment: (code from Python-3.8.0b3, but Python-3.7.2 had similar issues) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 08:26:57 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Fri, 09 Aug 2019 12:26:57 +0000 Subject: [issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...) In-Reply-To: <1565351601.24.0.515340331062.issue37801@roundup.psfhosted.org> Message-ID: <1565353617.81.0.954550875562.issue37801@roundup.psfhosted.org> Change by Emmanuel Arias : ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 08:31:44 2019 From: report at bugs.python.org (Kubilay Kocak) Date: Fri, 09 Aug 2019 12:31:44 +0000 Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org> Message-ID: <1565353904.48.0.525792805141.issue37788@roundup.psfhosted.org> Change by Kubilay Kocak : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 09:25:31 2019 From: report at bugs.python.org (Michael Anckaert) Date: Fri, 09 Aug 2019 13:25:31 +0000 Subject: [issue26131] Raise ImportWarning when loader.load_module() is used In-Reply-To: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za> Message-ID: <1565357131.64.0.579901496756.issue26131@roundup.psfhosted.org> Michael Anckaert added the comment: I checked out the source (Lib/imp.py:219) and only see the docstring marking this method als Deprecated. No exceptions are being raised. I would like to work on this issue. ---------- nosy: +michaelanckaert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 09:27:40 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Fri, 09 Aug 2019 13:27:40 +0000 Subject: [issue37802] micro-optimization of PyLong_FromSize_t() Message-ID: <1565357260.71.0.37857302813.issue37802@roundup.psfhosted.org> New submission from Sergey Fedoseev : Currently PyLong_FromSize_t() uses PyLong_FromLong() for values < PyLong_BASE. It's suboptimal because PyLong_FromLong() needs to handle the sign. Removing PyLong_FromLong() call and handling small ints directly in PyLong_FromSize_t() makes it faster: $ python -m perf timeit -s "from itertools import repeat; _len = repeat(None, 2).__length_hint__" "_len()" --compare-to=../cpython-master/venv/bin/python --duplicate=10000 /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 18.7 ns +- 0.3 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 16.7 ns +- 0.1 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 18.7 ns +- 0.3 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 16.7 ns +- 0.1 ns: 1.12x faster (-10%) $ python -m perf timeit -s "from itertools import repeat; _len = repeat(None, 2**10).__length_hint__" "_len()" --compare-to=../cpython-master/venv/bin/python --duplicate=10000 /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 26.2 ns +- 0.0 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 25.0 ns +- 0.7 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 26.2 ns +- 0.0 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 25.0 ns +- 0.7 ns: 1.05x faster (-5%) $ python -m perf timeit -s "from itertools import repeat; _len = repeat(None, 2**30).__length_hint__" "_len()" --compare-to=../cpython-master/venv/bin/python --duplicate=10000 /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 25.6 ns +- 0.1 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 25.6 ns +- 0.0 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 25.6 ns +- 0.1 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 25.6 ns +- 0.0 ns: 1.00x faster (-0%) This change makes PyLong_FromSize_t() consistently faster than PyLong_FromSsize_t(). So it might make sense to replace PyLong_FromSsize_t() with PyLong_FromSize_t() in __length_hint__() implementations and other similar cases. For example: $ python -m perf timeit -s "_len = iter(bytes(2)).__length_hint__" "_len()" --compare-to=../cpython-master/venv/bin/python --duplicate=10000 /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 19.4 ns +- 0.3 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 17.3 ns +- 0.1 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 19.4 ns +- 0.3 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 17.3 ns +- 0.1 ns: 1.12x faster (-11%) $ python -m perf timeit -s "_len = iter(bytes(2**10)).__length_hint__" "_len()" --compare-to=../cpython-master/venv/bin/python --duplicate=10000 /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 26.3 ns +- 0.1 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 25.3 ns +- 0.2 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 26.3 ns +- 0.1 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 25.3 ns +- 0.2 ns: 1.04x faster (-4%) $ python -m perf timeit -s "_len = iter(bytes(2**30)).__length_hint__" "_len()" --compare-to=../cpython-master/venv/bin/python --duplicate=10000 /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 27.6 ns +- 0.1 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 26.0 ns +- 0.1 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 27.6 ns +- 0.1 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 26.0 ns +- 0.1 ns: 1.06x faster (-6%) ---------- components: Interpreter Core messages: 349285 nosy: sir-sigurd priority: normal severity: normal status: open title: micro-optimization of PyLong_FromSize_t() type: performance versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 09:29:44 2019 From: report at bugs.python.org (Michael Anckaert) Date: Fri, 09 Aug 2019 13:29:44 +0000 Subject: [issue26131] Raise ImportWarning when loader.load_module() is used In-Reply-To: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za> Message-ID: <1565357384.87.0.974707302767.issue26131@roundup.psfhosted.org> Michael Anckaert added the comment: Clarification: the imp module shows a DeprecationWarning when imported. Was this what was meant? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 09:30:05 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Fri, 09 Aug 2019 13:30:05 +0000 Subject: [issue37802] micro-optimization of PyLong_FromSize_t() In-Reply-To: <1565357260.71.0.37857302813.issue37802@roundup.psfhosted.org> Message-ID: <1565357405.81.0.415681841713.issue37802@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- keywords: +patch pull_requests: +14924 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15192 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 09:30:31 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 09 Aug 2019 13:30:31 +0000 Subject: [issue26131] Raise ImportWarning when loader.load_module() is used In-Reply-To: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za> Message-ID: <1565357431.23.0.183339728066.issue26131@roundup.psfhosted.org> Joannah Nanjekye added the comment: Feel free to open a PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 10:15:50 2019 From: report at bugs.python.org (Jordon.X) Date: Fri, 09 Aug 2019 14:15:50 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in some files In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1565360150.3.0.56441507366.issue37752@roundup.psfhosted.org> Jordon.X <9651234 at qq.com> added the comment: Hi Ma, I think this is a very valuable suggestion. And if we want to delete the definition of Py_CHARMASK, maybe another issue needed. I am not very sure about the considerations of this macro definition. And whether there are any side effects after deletion needs further discussion. Thanks, Best Regards ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 10:21:22 2019 From: report at bugs.python.org (Paul Moore) Date: Fri, 09 Aug 2019 14:21:22 +0000 Subject: [issue36714] Tweak doctest 'example' regex to allow a leading ellipsis in 'want' line In-Reply-To: <1556122958.82.0.669799236777.issue36714@roundup.psfhosted.org> Message-ID: <1565360482.92.0.898187699857.issue36714@roundup.psfhosted.org> Paul Moore added the comment: It shouldn't be hard to update the regex to accept either "... " followed by other text or "..." on a line on its own, surely? ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 10:22:21 2019 From: report at bugs.python.org (Paul Ganssle) Date: Fri, 09 Aug 2019 14:22:21 +0000 Subject: [issue37642] timezone allows no offset from range (23:59, 24:00) In-Reply-To: <1563709284.19.0.651842013894.issue37642@roundup.psfhosted.org> Message-ID: <1565360541.52.0.0890244844293.issue37642@roundup.psfhosted.org> Paul Ganssle added the comment: New changeset 92c7e30adf5c81a54d6e5e555a6bdfaa60157a0d by Paul Ganssle (Ngalim Siregar) in branch 'master': bpo-37642: Update acceptable offsets in timezone (GH-14878) https://github.com/python/cpython/commit/92c7e30adf5c81a54d6e5e555a6bdfaa60157a0d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 10:52:52 2019 From: report at bugs.python.org (daniel hahler) Date: Fri, 09 Aug 2019 14:52:52 +0000 Subject: [issue37803] "python -m pdb --help" does not work Message-ID: <1565362372.8.0.519393722004.issue37803@roundup.psfhosted.org> New submission from daniel hahler : The long options passed to `getopt.getopt` should not include the leading dashes: % python -m pdb --help Traceback (most recent call last): File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.7/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/daniel/src/pdbpp/pdb.py", line 1672, in pdb.main() File "/usr/lib/python3.7/pdb.py", line 1662, in main opts, args = getopt.getopt(sys.argv[1:], 'mhc:', ['--help', '--command=']) File "/usr/lib/python3.7/getopt.py", line 93, in getopt opts, args = do_longs(opts, args[0][2:], longopts, args[1:]) File "/usr/lib/python3.7/getopt.py", line 157, in do_longs has_arg, opt = long_has_args(opt, longopts) File "/usr/lib/python3.7/getopt.py", line 174, in long_has_args raise GetoptError(_('option --%s not recognized') % opt, opt) getopt.GetoptError: option --help not recognized (it works in Python 2.7) ---------- components: Library (Lib) messages: 349291 nosy: blueyed priority: normal severity: normal status: open title: "python -m pdb --help" does not work type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 10:54:09 2019 From: report at bugs.python.org (daniel hahler) Date: Fri, 09 Aug 2019 14:54:09 +0000 Subject: [issue37803] "python -m pdb --help" does not work In-Reply-To: <1565362372.8.0.519393722004.issue37803@roundup.psfhosted.org> Message-ID: <1565362449.67.0.815892601664.issue37803@roundup.psfhosted.org> Change by daniel hahler : ---------- keywords: +patch pull_requests: +14925 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15193 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 11:13:04 2019 From: report at bugs.python.org (daniel hahler) Date: Fri, 09 Aug 2019 15:13:04 +0000 Subject: [issue21161] list comprehensions don't see local variables in pdb in python3 In-Reply-To: <1396698943.39.0.489151150852.issue21161@psf.upfronthosting.co.za> Message-ID: <1565363584.76.0.160935130768.issue21161@roundup.psfhosted.org> Change by daniel hahler : ---------- pull_requests: +14926 pull_request: https://github.com/python/cpython/pull/15194 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 11:22:25 2019 From: report at bugs.python.org (Ned Deily) Date: Fri, 09 Aug 2019 15:22:25 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1565364145.35.0.318365185857.issue34155@roundup.psfhosted.org> Ned Deily added the comment: New changeset 13a19139b5e76175bc95294d54afc9425e4f36c9 by Ned Deily (Miss Islington (bot)) in branch '3.6': bpo-34155: Dont parse domains containing @ (GH-13079) (GH-14826) https://github.com/python/cpython/commit/13a19139b5e76175bc95294d54afc9425e4f36c9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 11:34:12 2019 From: report at bugs.python.org (Dong-hee Na) Date: Fri, 09 Aug 2019 15:34:12 +0000 Subject: [issue37804] Remove isAlive Message-ID: <1565364852.41.0.891047152339.issue37804@roundup.psfhosted.org> New submission from Dong-hee Na : As we discussed https://bugs.python.org/issue35283. Now is the time to remove Thread.isAlive. If it is okay, I 'd like to work on this issue. ---------- messages: 349293 nosy: asvetlov, corona10, vstinner priority: normal severity: normal status: open title: Remove isAlive versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 11:34:39 2019 From: report at bugs.python.org (Dong-hee Na) Date: Fri, 09 Aug 2019 15:34:39 +0000 Subject: [issue37804] Remove Thread.isAlive In-Reply-To: <1565364852.41.0.891047152339.issue37804@roundup.psfhosted.org> Message-ID: <1565364879.17.0.99902368959.issue37804@roundup.psfhosted.org> Change by Dong-hee Na : ---------- components: +Library (Lib) title: Remove isAlive -> Remove Thread.isAlive _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 12:43:53 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 09 Aug 2019 16:43:53 +0000 Subject: [issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...) In-Reply-To: <1565351601.24.0.515340331062.issue37801@roundup.psfhosted.org> Message-ID: <1565369033.82.0.980756156047.issue37801@roundup.psfhosted.org> Steve Dower added the comment: Guessing it needs an extra header file that is implicitly included in the Windows headers? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 12:50:43 2019 From: report at bugs.python.org (Brett Cannon) Date: Fri, 09 Aug 2019 16:50:43 +0000 Subject: [issue26131] Raise ImportWarning when loader.load_module() is used In-Reply-To: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za> Message-ID: <1565369443.78.0.261076999032.issue26131@roundup.psfhosted.org> Brett Cannon added the comment: If you look at https://github.com/python/cpython/blob/master/Lib/importlib/_bootstrap.py and https://github.com/python/cpython/blob/master/Lib/importlib/_bootstrap_external.py you will notice a bunch of comments near all the calls to load_module(). Those are the places that should be somehow triggering a DeprecationWarning. I think there's a compatibility shim function which would need to raise an exception so that anyone who has implemented load_module() as the only way to handle loading get a warning (but I think that requires certain loaders to have appropriate support which hopefully they have already but someone needs to double-check). After that every implementation of load_module() should have a warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 13:00:31 2019 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 09 Aug 2019 17:00:31 +0000 Subject: [issue37636] Deprecate slicing and ordering operations on sys.version In-Reply-To: <1563626755.13.0.11799518747.issue37636@roundup.psfhosted.org> Message-ID: <1565370031.24.0.0889633732959.issue37636@roundup.psfhosted.org> Nick Coghlan added the comment: Regarding the "Would releasing 4.0 instead avoid problems?" Anthony actually did that experiment, too: it broke third party projects even more impressively than the 3.10 build did. I think Serhiy's point is fairly compelling though - check whether or not pylint checks for this, and then close this issue with either a pointer to their documentation, or else a pointer to a feature request on their issue tracker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 13:03:12 2019 From: report at bugs.python.org (hai shi) Date: Fri, 09 Aug 2019 17:03:12 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in some files In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1565370192.85.0.655599503862.issue37752@roundup.psfhosted.org> hai shi added the comment: Due to this macro documented in https://docs.python.org/3.9/c-api/intro.html#c.Py_CHARMASK and we don't know how much user use this marco, I don't think we need delte this function(deleting operation should be careful). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 13:03:56 2019 From: report at bugs.python.org (hai shi) Date: Fri, 09 Aug 2019 17:03:56 +0000 Subject: [issue37752] Redundant Py_CHARMASK called in some files In-Reply-To: <1564834217.7.0.242563409504.issue37752@roundup.psfhosted.org> Message-ID: <1565370236.47.0.301890277158.issue37752@roundup.psfhosted.org> hai shi added the comment: typo error: delte->delete ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 13:13:44 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Fri, 09 Aug 2019 17:13:44 +0000 Subject: [issue12128] Allow an abc.abstractproperty to be overridden by an instance data attribute In-Reply-To: <1305911703.09.0.134249941544.issue12128@psf.upfronthosting.co.za> Message-ID: <1565370824.46.0.946440035215.issue12128@roundup.psfhosted.org> Sanyam Khurana added the comment: I was trying to search the mailing list archives for the URL posted by Eric: http://mail.python.org/pipermail/python-list/2011-May/1272604.html But I couldn't find it. Also that URL shows 404. Eric, is it possible for you to post the correct link? ---------- nosy: +CuriousLearner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 13:19:17 2019 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 09 Aug 2019 17:19:17 +0000 Subject: [issue37398] contextlib.ContextDecorator decorating async functions In-Reply-To: <1561445403.56.0.10750759042.issue37398@roundup.psfhosted.org> Message-ID: <1565371157.38.0.0704166699166.issue37398@roundup.psfhosted.org> Nick Coghlan added the comment: I wouldn't be OK with magic switching in the behaviour of ContextDecorator (that's not only semantically confusing, it's also going to make the contextlib function wrappers even slower than they already are). I'm also entirely unclear on what you would expect a synchronous context manager to do when applied to an asynchronous function, as embedding an "await" call inside a synchronous with statement is unlikely to end well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 13:23:35 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Fri, 09 Aug 2019 17:23:35 +0000 Subject: [issue16837] Number ABC can be instantiated In-Reply-To: <1357082763.61.0.378054227113.issue16837@psf.upfronthosting.co.za> Message-ID: <1565371415.63.0.0371697025149.issue16837@roundup.psfhosted.org> Sanyam Khurana added the comment: Hi Alexander, Can you please address the reviews and turn this patch into a GitHub PR, please? ---------- nosy: +CuriousLearner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 13:25:46 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Fri, 09 Aug 2019 17:25:46 +0000 Subject: [issue16837] Number ABC can be instantiated In-Reply-To: <1357082763.61.0.378054227113.issue16837@psf.upfronthosting.co.za> Message-ID: <1565371546.81.0.357656273304.issue16837@roundup.psfhosted.org> Sanyam Khurana added the comment: I'm changing the versions to Python 3.8 and 3.9 for this bug. ---------- versions: +Python 3.8, Python 3.9 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 13:52:50 2019 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Fri, 09 Aug 2019 17:52:50 +0000 Subject: [issue35712] Make NotImplemented unusable in boolean context In-Reply-To: <1547157306.18.0.725390794489.issue35712@roundup.psfhosted.org> Message-ID: <1565373170.06.0.233462496903.issue35712@roundup.psfhosted.org> Vedran ?a?i? added the comment: Another reason why current behavior is confusing: what do you think filter(2 .__eq__, 'text') should yield? :-o (Yes, I know this isn't the right way to do it, but (element for element in 'text' if element == 2) is twice longer.:) ---------- nosy: +veky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 14:06:25 2019 From: report at bugs.python.org (Brian Skinn) Date: Fri, 09 Aug 2019 18:06:25 +0000 Subject: [issue36714] Tweak doctest 'example' regex to allow a leading ellipsis in 'want' line In-Reply-To: <1556122958.82.0.669799236777.issue36714@roundup.psfhosted.org> Message-ID: <1565373985.6.0.472537969395.issue36714@roundup.psfhosted.org> Brian Skinn added the comment: Mm, agreed--that regex wouldn't be hard to write. The problem is, AFAICT there's irresolvable syntactic ambiguity in a line starting with exactly three periods, if the doctest PS2 specification is not constrained to be exactly "... ". In such a case, "..." could mark either (1) an ellipsis standing in for an entire line of 'want', or (2) a PS2, marking a blank line in 'source'. I don't really think aggressive lookahead would help much -- an arbitrary number of following lines could contain exactly "...", and the intended transition from 'source' to 'want' could lie at any one of them. The nonrecursive nature of regex is unhelpful here, but I don't think one could even write a recursive-descent parser, or similar, that could be 100% reliable on a single comparison. It would have to test the string against all the various splits between 'source' and 'want' along those "..." lines, and see if any match. Hairy mess. AFAICT, defining "... " as PS2, and "..." as 'ellipsis representing a whole line' is the cleanest solution from a logical point of view. Of course, then it's *visually* confusing, because trailing space. ?\_(?)_/? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 14:09:02 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Fri, 09 Aug 2019 18:09:02 +0000 Subject: [issue37785] argparse uses %s in gettext calls causing xgettext warnings In-Reply-To: <1565182156.22.0.512922989842.issue37785@roundup.psfhosted.org> Message-ID: <1565374142.07.0.245453969725.issue37785@roundup.psfhosted.org> Sanyam Khurana added the comment: Hi Jakub, Welcome and thank you for contributing. I've added a suggestion on your pull request. Python 3.6 and Python 3.5 are in security fixes stage, so I've removed those tags from this bug. ---------- nosy: +CuriousLearner type: -> behavior versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 14:33:32 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Fri, 09 Aug 2019 18:33:32 +0000 Subject: [issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode In-Reply-To: <1457738623.54.0.0867122071018.issue26543@psf.upfronthosting.co.za> Message-ID: <1565375612.15.0.725405150836.issue26543@roundup.psfhosted.org> Sanyam Khurana added the comment: Removing 3.5 as it is in security fix mode. Also, the PR just contains the test case that would trigger the condition and not the actual code. ---------- nosy: +CuriousLearner stage: -> patch review versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 14:35:37 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Fri, 09 Aug 2019 18:35:37 +0000 Subject: [issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode In-Reply-To: <1457738623.54.0.0867122071018.issue26543@psf.upfronthosting.co.za> Message-ID: <1565375737.18.0.417817814327.issue26543@roundup.psfhosted.org> Sanyam Khurana added the comment: Hey ankostis, Please let us know if you've time to complete the PR. Thank you :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 14:41:15 2019 From: report at bugs.python.org (Brian Skinn) Date: Fri, 09 Aug 2019 18:41:15 +0000 Subject: [issue36714] Tweak doctest 'example' regex to allow a leading ellipsis in 'want' line In-Reply-To: <1556122958.82.0.669799236777.issue36714@roundup.psfhosted.org> Message-ID: <1565376075.16.0.0207302531469.issue36714@roundup.psfhosted.org> Brian Skinn added the comment: I suppose one alternative solution might be to tweak the ELLIPSIS feature of doctest, such that it would interpret a run of >=3 periods in a row (matching regex pattern of "[.]{3,}") as 'ellipsis'. The regex for PS2 could then have a negative lookahead added, so that it *only* matches three periods, plus optionally other content: '\.\.\.(?!\.)' That way, a line like "... foo" would retain the current meaning of "'source' line, consisting of PS2 plus the identifier 'foo'", but the meaning of "arbitrary content followed by ' foo'" could be achieved by ".... foo", since the leading "...." would NOT match the negative lookahead for PS2. In other situations, where "..." is *not* the leading non-whitespace content, the old behavior suffices: the PS2 regex won't match anyways, so it'll be left for ELLIPSIS to process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 14:44:41 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 09 Aug 2019 18:44:41 +0000 Subject: [issue31226] shutil.rmtree fails when target has an internal directory junction (Windows) In-Reply-To: <1502978298.87.0.60982184572.issue31226@psf.upfronthosting.co.za> Message-ID: <1565376281.54.0.588812248045.issue31226@roundup.psfhosted.org> Eryk Sun added the comment: > Thanks for the detailed explanation Eryk. While it is a little > annoying that it comes 2 years after the initial proposed > solution, I'll happily take that if the end result is a better fix :) Mea culpa. I am sorry about that. I do respect your time and the work you've invested into this issue. I'm guilty of procrastination here. Plus we're in murky waters, and I'm worried about getting it wrong -- again. A lot of misleading information has been published about filesystem junctions. And Microsoft's documentation on the subject of reparse points and the expected behavior of symlinks, junctions, and other "name surrogates" is too brief, incomplete or just wrong. > this fix seems quite a bit more involved to implement than the > previous one. I was painting a broad picture of what it might look if we had general support for "name surrogate" reparse points. I went out of my way to use conditional tense, with "could" and "would" used extensively. I wanted to get that part covered upfront to be able to present a generic alternative solution to the rmtree() problem before digressing into the subject of junction and symlink behavior. For just this issue, we could use a local solution for Windows. One option would be to add an nt._getattrtaginfo function that calls CreateFileW and GetFileInformationByHandleEx: FileAttributeTagInfo, with a fallback to FindFirstFileW if that fails for a downlevel filesystem. Then wrap the os.scandir call with a function that checks for a name-surrogate tag. For example: if not _WINDOWS: _rmtree_unsafe_scandir = os.scandir else: import contextlib def _rmtree_unsafe_scandir(path): try: attr, tag = nt._getattrtaginfo(path) except OSError: attr = tag = 0 if (attr & stat.FILE_ATTRIBUTE_DIRECTORY and attr & stat.FILE_ATTRIBUTE_REPARSE_POINT and tag & 0x2000_0000): # IsReparseTagNameSurrogate return contextlib.nullcontext([]) else: return os.scandir(path) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 14:46:42 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Fri, 09 Aug 2019 18:46:42 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565376402.37.0.260308728943.issue32912@roundup.psfhosted.org> Change by Sanyam Khurana : ---------- nosy: +CuriousLearner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 15:32:50 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Fri, 09 Aug 2019 19:32:50 +0000 Subject: [issue34331] Incorrectly pluralized abstract class error message In-Reply-To: <1533311791.76.0.56676864532.issue34331@psf.upfronthosting.co.za> Message-ID: <1565379170.93.0.737601032579.issue34331@roundup.psfhosted.org> Sanyam Khurana added the comment: Adding 3.9 to this bug. I've reviewed the PR and it looks good to me. ---------- nosy: +CuriousLearner versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 15:52:24 2019 From: report at bugs.python.org (Kostis Anagnostopoulos) Date: Fri, 09 Aug 2019 19:52:24 +0000 Subject: [issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode In-Reply-To: <1565375737.18.0.417817814327.issue26543@roundup.psfhosted.org> Message-ID: Kostis Anagnostopoulos added the comment: Dear Sanyam, My apologies, it's been almost a year that i don't need the fix for this code, my app has been graciously decommissioned, and i don;t have any time for it. Best, Kostis On Fri, 9 Aug 2019 at 21:35, Sanyam Khurana wrote: > > Sanyam Khurana added the comment: > > Hey ankostis, > > Please let us know if you've time to complete the PR. > > Thank you :) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 15:53:33 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 09 Aug 2019 19:53:33 +0000 Subject: [issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...) In-Reply-To: <1565351601.24.0.515340331062.issue37801@roundup.psfhosted.org> Message-ID: <1565380413.21.0.234521569344.issue37801@roundup.psfhosted.org> Eryk Sun added the comment: I wasn't aware that CPython builds for MSYS2 out of the box, since it's a POSIX-on-Windows platform like Cygwin. Apparently there are patches that enable it to build, since MSYS2 has Python available. For Windows, WCSTOK expands to wcstok_s, which takes a context pointer that allows concurrently parsing multiple strings in a single thread. The old function lacks this parameter and instead uses a per-thread static buffer. They're declared as follows: wchar_t *wcstok(wchar_t *strToken, const wchar_t *strDelimit); wchar_t *wcstok_s(wchar_t *str, const wchar_t *delimiters, wchar_t **context); Otherwise the WCSTOK macro expands to wcstok, which assumes that POSIX systems use the standard definition [1]: wchar_t *wcstok(wchar_t *restrict ws1, const wchar_t *restrict ws2, wchar_t **restrict ptr); Apparently the version of wcstok declared in your build environment takes only two arguments, like the old insecure function in Windows: wchar_t *__cdecl wcstok(wchar_t * __restrict__ _Str, const wchar_t * __restrict__ _Delim) __MINGW_ATTRIB_DEPRECATED_SEC_WARN; [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/wcstok.html ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 16:18:19 2019 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 09 Aug 2019 20:18:19 +0000 Subject: [issue37398] contextlib.ContextDecorator decorating async functions In-Reply-To: <1561445403.56.0.10750759042.issue37398@roundup.psfhosted.org> Message-ID: <1565381899.28.0.872734763284.issue37398@roundup.psfhosted.org> Nathaniel Smith added the comment: > I wouldn't be OK with magic switching in the behaviour of ContextDecorator (that's not only semantically confusing, it's also going to make the contextlib function wrappers even slower than they already are). I hear you on the semantic confusion, but is a single check at definition time really that expensive? The runtime cost is zero. > I'm also entirely unclear on what you would expect a synchronous context manager to do when applied to an asynchronous function, as embedding an "await" call inside a synchronous with statement is unlikely to end well. It would be like: async def blah(): with something(): await foo() There's nothing weird about this; people write the long version all the time. You'd only do it when 'something()' doesn't do I/O, but there are lots of context managers that don't do I/O. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 16:25:51 2019 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 09 Aug 2019 20:25:51 +0000 Subject: [issue37398] contextlib.ContextDecorator decorating async functions In-Reply-To: <1561445403.56.0.10750759042.issue37398@roundup.psfhosted.org> Message-ID: <1565382351.77.0.86167989256.issue37398@roundup.psfhosted.org> Yury Selivanov added the comment: > I hear you on the semantic confusion, but is a single check at definition time really that expensive? Do you know how to make that single check 100% reliable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 16:26:44 2019 From: report at bugs.python.org (Tal Einat) Date: Fri, 09 Aug 2019 20:26:44 +0000 Subject: [issue23666] Add shell session logging option to IDLE In-Reply-To: <1426376285.32.0.372835851361.issue23666@psf.upfronthosting.co.za> Message-ID: <1565382404.68.0.268387043521.issue23666@roundup.psfhosted.org> Tal Einat added the comment: I'm happy to look into implementing this. Also perhaps auto-saved backups for edited files. Where would you suggest the files be kept? The user's .idlerc directory? ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 16:32:23 2019 From: report at bugs.python.org (Nathaniel Smith) Date: Fri, 09 Aug 2019 20:32:23 +0000 Subject: [issue37398] contextlib.ContextDecorator decorating async functions In-Reply-To: <1561445403.56.0.10750759042.issue37398@roundup.psfhosted.org> Message-ID: <1565382743.0.0.0322561276934.issue37398@roundup.psfhosted.org> Nathaniel Smith added the comment: @Yury: depends on what you mean by "100% reliable" :-). Like I said above, I'm normally super against automagic detection of sync-vs-async functions because of all the edge cases where it goes wrong, but in this specific case where people are writing a decorator one line above their def/async def, I think a simple iscoroutinefunction check will be pretty close to 100% matching what users expect. Or, if we don't change the semantics, then we can still be 100% confident that if iscoroutinefunction returns true, then the user has made a mistake. (I.e., if we make this issue a warning, then it's possible we'll miss print a warning in some complicated cases, but we can be confident that all the warnings we do print are correct.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 17:54:43 2019 From: report at bugs.python.org (Julian Berman) Date: Fri, 09 Aug 2019 21:54:43 +0000 Subject: [issue37805] json.dump(..., skipkeys=True) has no unit tests Message-ID: <1565387683.62.0.51432990737.issue37805@roundup.psfhosted.org> New submission from Julian Berman : Looks like there possibly are upstream tests that could be pulled in with modification: https://github.com/simplejson/simplejson/blob/00ed20da4c0e5f0396661f73482418651ff4d8c7/simplejson/tests/test_dump.py#L53-L66 (Found via https://bitbucket.org/pypy/pypy/issues/3052/json-skipkeys-true-results-in-invalid-json) ---------- components: Tests messages: 349317 nosy: Julian priority: normal severity: normal status: open title: json.dump(..., skipkeys=True) has no unit tests versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 18:34:28 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 09 Aug 2019 22:34:28 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565390068.06.0.361420726911.issue32912@roundup.psfhosted.org> Gregory P. Smith added the comment: New changeset 4c5b6bac2408f879231c7cd38d67657dd4804e7c by Gregory P. Smith (Serhiy Storchaka) in branch '3.8': [3.8] bpo-32912: Revert SyntaxWarning on invalid escape sequences (GH-15142) https://github.com/python/cpython/commit/4c5b6bac2408f879231c7cd38d67657dd4804e7c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 18:50:16 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 09 Aug 2019 22:50:16 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565391016.71.0.969067509316.issue32912@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- pull_requests: +14927 pull_request: https://github.com/python/cpython/pull/15195 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 18:58:37 2019 From: report at bugs.python.org (Kostis Anagnostopoulos) Date: Fri, 09 Aug 2019 22:58:37 +0000 Subject: [issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode In-Reply-To: Message-ID: Kostis Anagnostopoulos added the comment: > > BTW, i went back to my code and pasted what seemed to cure the problem, > added in commit 2b99cec in my PR. But i don't have much time to track if it really works. I hope it will help you resolve the issue. Best, Kostis ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 19:11:49 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 09 Aug 2019 23:11:49 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565392309.17.0.50188389159.issue32912@roundup.psfhosted.org> Raymond Hettinger added the comment: Thank you! ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 19:22:49 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 09 Aug 2019 23:22:49 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565392969.8.0.877403169398.issue32912@roundup.psfhosted.org> Gregory P. Smith added the comment: I'm leaving this open, as we may still want to do it in 3.9+, just in a less disruptive manner. (That, and how, hasn't been decided yet) Follow the thread(s) on python-dev for the latest on that. ---------- resolution: fixed -> stage: resolved -> status: closed -> open versions: +Python 3.9 -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 19:52:14 2019 From: report at bugs.python.org (Aaron Meurer) Date: Fri, 09 Aug 2019 23:52:14 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565394734.9.0.0522234590577.issue32912@roundup.psfhosted.org> Aaron Meurer added the comment: Are there issues tracking the things I mentioned, which should IMO happen before this becomes a hard error (making the warnings reproduce even if the file has already been compiled, and making warning message point to the correct line in multiline strings)? And is it too late to potentially get some of those things in 3.8? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 20:15:00 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 10 Aug 2019 00:15:00 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565396100.79.0.611186702139.issue32912@roundup.psfhosted.org> Gregory P. Smith added the comment: I haven't looked, so not that i'm aware of. I suggest filing one for each of those. The warning not pointing to the right line in a multiline literal sounds like a bug to me so that one, if fixed, seems reasonable for 3.8. The release manager gets to decide. Making the syntax warnings happen upon import of an already compiled pyc is more feature-ish, likely to be 3.9+. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 21:40:11 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Sat, 10 Aug 2019 01:40:11 +0000 Subject: [issue37799] Renaming Doc/reference/ to Doc/language/ In-Reply-To: <1565343528.85.0.0920762754632.issue37799@roundup.psfhosted.org> Message-ID: <1565401211.64.0.896787966657.issue37799@roundup.psfhosted.org> Emmanuel Arias added the comment: Hello maggyero, I thinks that could be a good improve. But this structure is used on since old cpython versions, so I don't know if it will be a necessary change. But, if you don't receive some feedback from here, you can propose a PR, maybe other core dev could review it and tell you their opinion :-) ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 22:36:54 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Aug 2019 02:36:54 +0000 Subject: [issue16837] Number ABC can be instantiated In-Reply-To: <1357082763.61.0.378054227113.issue16837@psf.upfronthosting.co.za> Message-ID: <1565404614.85.0.739221803551.issue16837@roundup.psfhosted.org> Raymond Hettinger added the comment: Usually, setting hash to None is the proper way to turn-off hashability. And it's possible that existing code has subclassed Number and provided other methods but not __hash__, so this could potentially break their code. On the other hand, it would be desirable to prevent instantiation, perhaps using some other mechanism would be better. I'll take a deeper look at this when I get a chance. ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 23:08:27 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Aug 2019 03:08:27 +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: <1565406507.88.0.972939200448.issue14465@roundup.psfhosted.org> Raymond Hettinger added the comment: FWIW, here is the relevant section of the XML specification, https://www.w3.org/TR/2008/REC-xml-20081126/#sec-white-space : """In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines) to set apart the markup for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document. On the other hand, "significant" white space that should be preserved in the delivered version is common, for example in poetry and source code. An XML processor must always pass all characters in a document that are not markup through to the application. A validating XML processor must also inform the application which of these characters constitute white space appearing in element content. """ OTOH, the java TransformerFactory does support a property, OutputKeys.INDENT, so there is a precedent for this feature request. Stefan, would you please make a final determination or pronouncement on whether this makes sense for ElementTree or whether it is outside the scope of what the module is trying to accomplish. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 9 23:21:57 2019 From: report at bugs.python.org (Brian Skinn) Date: Sat, 10 Aug 2019 03:21:57 +0000 Subject: [issue36714] Tweak doctest 'example' regex to allow a leading ellipsis in 'want' line In-Reply-To: <1556122958.82.0.669799236777.issue36714@roundup.psfhosted.org> Message-ID: <1565407317.77.0.751362204226.issue36714@roundup.psfhosted.org> Brian Skinn added the comment: On reflection, it would probably be better to limit the ELLIPSIS to 3 or 4 periods ('[.]{3,4}'); otherwise, it would be impossible to express an ellipsis followed by a period in a 'want'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 00:26:11 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Aug 2019 04:26:11 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565411171.78.0.387409197981.issue32912@roundup.psfhosted.org> Raymond Hettinger added the comment: One possibility is to restrict the warning to a backslash followed by an alphabetic character or backslash, and that we define backslash followed by any other printable character as specifically allowed. This would catch the likely sources of errors without breaking the likes of \, or \-. Also, multiline strings have less of a need for a warning than a single line string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 00:47:14 2019 From: report at bugs.python.org (Mariatta) Date: Sat, 10 Aug 2019 04:47:14 +0000 Subject: [issue37799] Renaming Doc/reference/ to Doc/language/ In-Reply-To: <1565343528.85.0.0920762754632.issue37799@roundup.psfhosted.org> Message-ID: <1565412434.08.0.433693401346.issue37799@roundup.psfhosted.org> Mariatta added the comment: The change is not worth doing for several reasons: - renaming filename/directory breaks git history on GitHub web UI. The history can still be viewed if you use the command line e.g. git log --follow. - other pages like stack overflow or blog posts have linked to the /reference for ages. We'll be breaking links. We might be able to set up redirect to the new path, but the effort is not worth the gain IMO. There is very little to be gained compared to all the pitfalls. So I'm closing this issue. Thanks. ---------- nosy: +Mariatta priority: normal -> low resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 01:26:57 2019 From: report at bugs.python.org (Valerio G) Date: Sat, 10 Aug 2019 05:26:57 +0000 Subject: [issue37806] Infinite recursion with typing.get_type_hints Message-ID: <1565414817.02.0.248356075738.issue37806@roundup.psfhosted.org> New submission from Valerio G : I encountered one condition where calling get_type_hints causes infinite recursion when dealing with forward declaration and cyclic types. Here's an example: from typing import Union, List, get_type_hints ValueList = List['Value'] Value = Union[str, ValueList] class A: a: List[Value] get_type_hints(A, globals(), locals()) This reaches the recursion limit as of 3.8.0b2. It seems that the combining _GenericAlias with ForwardRef is what triggers this condition: ForwardRef._evaluate sets __forward_value__ on its first call on a given instance _GenericAlias tries to compare its args post evaluation If one of the arguments is a previously evaluated forward reference containing a cycle, then it will infinitely recurse in the hash function when building a frozen set for the comparison. The above is, of course, a very artificial example, but I can imagine this happening a lot in code with trees or similar structures. My initial reproduction case was using _eval_type to resolve forward references returned by get_args (side note: it would be nice to have a public function to do that). ---------- components: Library (Lib) messages: 349330 nosy: vg0377467 priority: normal severity: normal status: open title: Infinite recursion with typing.get_type_hints versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 01:32:30 2019 From: report at bugs.python.org (Valerio G) Date: Sat, 10 Aug 2019 05:32:30 +0000 Subject: [issue37806] Infinite recursion with typing.get_type_hints In-Reply-To: <1565414817.02.0.248356075738.issue37806@roundup.psfhosted.org> Message-ID: <1565415150.13.0.800872008493.issue37806@roundup.psfhosted.org> Change by Valerio G : ---------- type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 01:48:38 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Aug 2019 05:48:38 +0000 Subject: [issue16837] Number ABC can be instantiated In-Reply-To: <1357082763.61.0.378054227113.issue16837@psf.upfronthosting.co.za> Message-ID: <1565416118.93.0.985319459824.issue16837@roundup.psfhosted.org> Raymond Hettinger added the comment: I looked into this a bit more and don't see another non-invasive way of blocking instantiation. Marking for Guido to take a look at. He's the expert on ABCs and typing and is the originator of the __hash__ = None approach to turning off hashability. Guido, would you like number subclasses to require an override of __hash__ or is the accidental instantiation of Number() something we even care about (I think this unlikely to ever arise in practice)? My suggestion is to deem it harmless and leave it as is. ---------- assignee: rhettinger -> gvanrossum nosy: +gvanrossum versions: +Python 2.7 -Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 01:50:27 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Aug 2019 05:50:27 +0000 Subject: [issue37636] Deprecate slicing and ordering operations on sys.version In-Reply-To: <1563626755.13.0.11799518747.issue37636@roundup.psfhosted.org> Message-ID: <1565416227.2.0.133824236531.issue37636@roundup.psfhosted.org> Raymond Hettinger added the comment: > Regarding the "Would releasing 4.0 instead avoid problems?" > Anthony actually did that experiment, too: it broke third > party projects even more impressively than the 3.10 build did. That's good to know. Please thank Anthony for doing his homework. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 02:24:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Aug 2019 06:24:06 +0000 Subject: [issue37807] Make hash() return a non-negative number Message-ID: <1565418246.0.0.695379140642.issue37807@roundup.psfhosted.org> New submission from Raymond Hettinger : The existing API for the builtin hash() function is inconvenient. When implementing structure that use a hash value, you never want a negative number. Running abs(hash(x)) works but is awkward, slower, and loses one bit of entropy. ---------- components: Interpreter Core messages: 349333 nosy: rhettinger, tim.peters priority: normal severity: normal status: open title: Make hash() return a non-negative number type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 03:17:16 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 Aug 2019 07:17:16 +0000 Subject: [issue23666] Add shell session logging option to IDLE In-Reply-To: <1426376285.32.0.372835851361.issue23666@psf.upfronthosting.co.za> Message-ID: <1565421436.56.0.416763652474.issue23666@roundup.psfhosted.org> Terry J. Reedy added the comment: A dirty editor must be saved before running, or discarded before closing. Neither is true for Shell, Making these at least an option in Shell should be the first change. If the user has specified a savefile name, that should be used, and the user is responsible for the file. If a file is automatically put, say, in .idlerc/shell.bak.py, there is an issue of when to delete or overwrite. We should continue working to make automatic, versus explicit, shell logging less necessary. If IDLE running in normal mode (user code running in a separate process) either closes by itself or locks up so that it *must* be closed, that should indicates a bug in python or IDLE that should be fixed. There might be a couple such bugs left, I am not sure. If the user process closes, the shell should restart one automatically. As far as I know, it dies. If the user process hangs, control-C (Shell => Interrupt Execution) usually works, >>> while 1: 2+2 KeyboardInterrupt >>> But a) beginning computer user may not know about ^C, or it may not work due to limitations in Python. (There is an issue about the latter.) In the latter case, one can restart with Shell => Restart Shell, but this is IDLE specific and users may not know about it. When the shell catches ^C, it could create an after callback with a delay of, say, .5 seconds (but to be determined). If ^C works, cancel the callback. If not, display a message (only once per session) about using Restart. Maybe next time, do an auto restart. We might also think about detecting a hang (5 seconds, no output?) and printing a message about using ^C. ---------- assignee: -> terry.reedy stage: -> test needed versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 03:19:15 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 10 Aug 2019 07:19:15 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565421555.64.0.683227967538.issue32912@roundup.psfhosted.org> miss-islington added the comment: New changeset b4be87a04a2a8ccfd2480e19dc527589fce53555 by Miss Islington (bot) (Gregory P. Smith) in branch 'master': bpo-32912: Revert SyntaxWarning on invalid escape sequences. (GH-15195) https://github.com/python/cpython/commit/b4be87a04a2a8ccfd2480e19dc527589fce53555 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 03:31:54 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 10 Aug 2019 07:31:54 +0000 Subject: [issue37806] Infinite recursion with typing.get_type_hints In-Reply-To: <1565414817.02.0.248356075738.issue37806@roundup.psfhosted.org> Message-ID: <1565422314.01.0.781044892282.issue37806@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +gvanrossum, levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 03:58:45 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 Aug 2019 07:58:45 +0000 Subject: [issue37756] Error 0x80070643 when installing In-Reply-To: <1564932178.65.0.171539834023.issue37756@roundup.psfhosted.org> Message-ID: <1565423925.03.0.338727606009.issue37756@roundup.psfhosted.org> Terry J. Reedy added the comment: The error comes from Windows and it indicates a problem with your computer. Questions about Windows errors should be initially directed to python-list or elsewhere. Searching for 0x80070643 returns multiple hits, including this 'official' one. https://answers.microsoft.com/en-us/insider/forum/all/windows-update-error-0x80070643/3bad0495-dabb-4e3f-91a7-aaf992ef537a You could also search stackoverflow.com. ---------- nosy: +terry.reedy resolution: -> not a bug stage: -> resolved status: open -> closed type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 04:16:47 2019 From: report at bugs.python.org (Christoph Reiter) Date: Sat, 10 Aug 2019 08:16:47 +0000 Subject: [issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...) In-Reply-To: <1565351601.24.0.515340331062.issue37801@roundup.psfhosted.org> Message-ID: <1565425007.02.0.412390223957.issue37801@roundup.psfhosted.org> Christoph Reiter added the comment: > I wasn't aware that CPython builds for MSYS2 out of the box, since it's a POSIX-on-Windows platform like Cygwin. Apparently there are patches that enable it to build, since MSYS2 has Python available. MSYS2 consists of a cygwin like environment and a mingw one. OP is trying to build with mingw. MSYS2 contains a somewhat heavily patched Python in both environments so it's expected that building plain CPython doesn't work. There are plans to upstream smaller non-MSYS2 specific patches but nothing has come of it so far. ---------- nosy: +lazka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 04:17:59 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 10 Aug 2019 08:17:59 +0000 Subject: [issue37808] Deprecate unbound super methods Message-ID: <1565425079.51.0.763493261864.issue37808@roundup.psfhosted.org> New submission from Steven D'Aprano : As per the discussion here, let's deprecate unbound super methods. https://discuss.python.org/t/is-it-time-to-deprecate-unbound-super-methods/1833 ---------- messages: 349338 nosy: steven.daprano priority: normal severity: normal status: open title: Deprecate unbound super methods versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 04:35:00 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Sat, 10 Aug 2019 08:35:00 +0000 Subject: [issue37809] Alias typing.NamedTuple to collections Message-ID: <1565426100.13.0.700794454326.issue37809@roundup.psfhosted.org> New submission from Steven D'Aprano : As discussed in the thread starting here with Guido's message: https://mail.python.org/archives/list/python-ideas at python.org/message/WTBXYJJ7CSGDLLJHHPHSH5ZCCA4C7QEP/ and these two follow-ups: https://mail.python.org/archives/list/python-ideas at python.org/message/SXF3RKYQ6DXFKX2RFMUDUKAWQEGXGHP3/ https://mail.python.org/archives/list/python-ideas at python.org/message/VRCH56CHE4P7IAWO7QRA6TDBISLONGQT/ we should do a better job of advertising typing.NamedTuple by aliasing it in the collections module. (I'm not sure if this can still go into 3.8, since it's not really a new feature, or if its too late.) ---------- messages: 349339 nosy: gvanrossum, levkivskyi, steven.daprano priority: normal severity: normal status: open title: Alias typing.NamedTuple to collections versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 09:09:42 2019 From: report at bugs.python.org (Eryk Sun) Date: Sat, 10 Aug 2019 13:09:42 +0000 Subject: [issue37756] Error 0x80070643 when installing In-Reply-To: <1564932178.65.0.171539834023.issue37756@roundup.psfhosted.org> Message-ID: <1565442582.59.0.696468291921.issue37756@roundup.psfhosted.org> Eryk Sun added the comment: If we see 0x8XXX_XXXX, it's either an NTSTATUS [1] warning, which is unlikely, or and HRESULT [2] error, which is very likely. One of the more common facility codes for HRESULT is the Windows API, 0x007. If we see 0x8007XXXX, then XXXX is a Windows system error code [3]. In this case, 0x643 is ERROR_INSTALL_FAILURE (1603), which is not a very information error code by itself. We need to read the log file (or request additional logs) to figure out what failed. Steve Dower is the person to address this, since he has far more experience with the design and behavior of the installer. From what I can see on the surface, with my shallow knowledge, it failed to install core_JustForMe for some reason (probably there's more info in another log), and then failed to delete the cached package when rolling back, with the error 0x80070003 (ERROR_PATH_NOT_FOUND), which looks suspicious. I'm reopening for now. Feel free to close it again if you disagree. I won't press the matter. [1] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/87fba13e-bf06-450e-83b1-9241dc81e781 [2] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/0642cb2f-2075-4469-918c-4441e69c548a [3] https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes ---------- nosy: +eryksun resolution: not a bug -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 11:36:12 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 10 Aug 2019 15:36:12 +0000 Subject: [issue37807] Make hash() return a non-negative number In-Reply-To: <1565418246.0.0.695379140642.issue37807@roundup.psfhosted.org> Message-ID: <1565451372.23.0.892678255582.issue37807@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +14928 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15199 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 11:40:20 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 10 Aug 2019 15:40:20 +0000 Subject: [issue37807] Make hash() return a non-negative number In-Reply-To: <1565418246.0.0.695379140642.issue37807@roundup.psfhosted.org> Message-ID: <1565451620.5.0.0470437066428.issue37807@roundup.psfhosted.org> Serhiy Storchaka added the comment: The only problem is that the current algorithm for numeric types is documented to return negative numbers. https://docs.python.org/3/library/stdtypes.html#hashing-of-numeric-types ---------- nosy: +mark.dickinson, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 12:36:05 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Aug 2019 16:36:05 +0000 Subject: [issue37807] Make hash() return a non-negative number In-Reply-To: <1565418246.0.0.695379140642.issue37807@roundup.psfhosted.org> Message-ID: <1565454965.25.0.221274181402.issue37807@roundup.psfhosted.org> Raymond Hettinger added the comment: We think can clarify that those docs describe int.__hash__, float.__hash__, and complex.__hash__. The builtin hash() function can and does make transformations on the result from the __dunder__ method: >>> class A: def __hash__(self): return 123423412341234123412341234 >>> hash(A()) 1656462513496965462 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 12:37:43 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Aug 2019 16:37:43 +0000 Subject: [issue37809] Alias typing.NamedTuple to collections In-Reply-To: <1565426100.13.0.700794454326.issue37809@roundup.psfhosted.org> Message-ID: <1565455063.09.0.516775895768.issue37809@roundup.psfhosted.org> Raymond Hettinger added the comment: > we should do a better job of advertising typing.NamedTuple FWIW, I had updated the docs for namedtuple() to link to typing.NamedTuple. I think that should suffice. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 12:41:45 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sat, 10 Aug 2019 16:41:45 +0000 Subject: [issue37809] Alias typing.NamedTuple to collections In-Reply-To: <1565426100.13.0.700794454326.issue37809@roundup.psfhosted.org> Message-ID: <1565455305.2.0.694552683044.issue37809@roundup.psfhosted.org> Ivan Levkivskyi added the comment: > FWIW, I had updated the docs for namedtuple() to link to typing.NamedTuple. I think that should suffice. Thank you! I looked at the docs everything looks good. I think this can be closed now. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 12:46:23 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Sat, 10 Aug 2019 16:46:23 +0000 Subject: [issue37806] Infinite recursion with typing.get_type_hints In-Reply-To: <1565414817.02.0.248356075738.issue37806@roundup.psfhosted.org> Message-ID: <1565455583.6.0.704865826937.issue37806@roundup.psfhosted.org> Change by Ivan Levkivskyi : ---------- assignee: -> levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 12:50:42 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Aug 2019 16:50:42 +0000 Subject: [issue37809] Alias typing.NamedTuple to collections In-Reply-To: <1565426100.13.0.700794454326.issue37809@roundup.psfhosted.org> Message-ID: <1565455842.44.0.387482447558.issue37809@roundup.psfhosted.org> Raymond Hettinger added the comment: Further notes for posterity: * Anything written using collections.NamedTuple would instantly lose its backwards compatibility. * The casing of NamedTuple is more in line with the typing module: List, Deque, NamedTuple and doesn't fit well with the deque, namedtuple, and ChainMap in the collections module. * Nothing in the collections module currently requires typing, but NamedTuple can only be used with typing. * We really don't want to increase import times for collections. This proposal would defeat the entire purpose of having moved _collections_abc to a separate module outside of the collections package. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 13:06:16 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 10 Aug 2019 17:06:16 +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: <1565456776.87.0.607158537562.issue14465@roundup.psfhosted.org> Stefan Behnel added the comment: The spec section that Raymond quoted makes it clear that pretty printing is not for everyone. But there are many use cases where it is 1) helpful, 2) leads to correct results, and 3) does not grow the file size excessively. Whoever wants to make use of it is probably in such a situation. I think adding some kind of support in the standard library would be nice, but it should not hurt "normal" uses, especially when a lot of data is involved. I'll send a PR that adds an indent() function to pre-process trees. Comments welcome. ---------- assignee: serhiy.storchaka -> scoder versions: +Python 3.9 -Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 13:06:37 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 10 Aug 2019 17:06:37 +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: <1565456797.67.0.192357096267.issue14465@roundup.psfhosted.org> Change by Stefan Behnel : ---------- pull_requests: +14929 pull_request: https://github.com/python/cpython/pull/15200 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 13:19:15 2019 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 10 Aug 2019 17:19:15 +0000 Subject: [issue37807] Make hash() return a non-negative number In-Reply-To: <1565418246.0.0.695379140642.issue37807@roundup.psfhosted.org> Message-ID: <1565457555.82.0.518726597367.issue37807@roundup.psfhosted.org> Mark Dickinson added the comment: This is a change of documented behaviour that will affect 3rd party libraries that provide numeric types, like NumPy and gmpy; it should not be done lightly. I think such a change deserves at least a deprecation warning, and should also be discussed more widely than just this issue. ---------- nosy: +njs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 14:31:26 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 10 Aug 2019 18:31:26 +0000 Subject: [issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity In-Reply-To: <1565258224.48.0.98423013878.issue37792@roundup.psfhosted.org> Message-ID: <1565461886.5.0.332935749936.issue37792@roundup.psfhosted.org> Stefan Behnel added the comment: FWIW, deep traversing an XML tree on an operation as simple as "==" seems excessive. To me, object identity comparison seems the most sensible behaviour of "==" on Element objects. (It's not "complicated to implement", but rather can be very expensive to execute.) Regarding your other questions (and note that this is a bug tracker, so discussing unrelated questions in a ticket is inappropriate ? use the Python mailing list instead if you want): "SubElement" suggests a constructor, yes. It kind-of makes sense, given what it does, and resembles "Element", which is the constructor for a (non-sub) Element. It might seem funny, sure, but on the other hand, why should users be bothered with the implementation detail that it is a function? :-) "fromstringlist()" matches "tostringlist()", API-wise. Both are probably not very widely used, but I don't see much value in removing them. It always breaks someone's code out there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 14:32:40 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 10 Aug 2019 18:32:40 +0000 Subject: [issue37807] Make hash() return a non-negative number In-Reply-To: <1565418246.0.0.695379140642.issue37807@roundup.psfhosted.org> Message-ID: <1565461960.41.0.979373812339.issue37807@roundup.psfhosted.org> Serhiy Storchaka added the comment: Currently the hash for integers and several other types uses 62 bits of 64 (on 64-bit platform). The domain of values is continuous: -sys.hash_info.modulus < h < sys.hash_info.modulus If interpret Py_hash_t as Py_uhash_t, it will no longer be continuous: 0 <= h < sys.hash_info.modulus or 2**sys.hash_info.width-sys.hash_info.modulus < h < 2**sys.hash_info.width The hash for tuples is written in term of signed hashes of elements. If write it in Python it will look more complicated for unsigned hashes. What are problems with using negative hash values? In hash tables you squeeze it to valid range by evaluating `h % size` of `h & mask`. Both expressions give non-negative result. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 14:33:42 2019 From: report at bugs.python.org (Tim Peters) Date: Sat, 10 Aug 2019 18:33:42 +0000 Subject: [issue37807] Make hash() return a non-negative number In-Reply-To: <1565418246.0.0.695379140642.issue37807@roundup.psfhosted.org> Message-ID: <1565462022.63.0.869397619089.issue37807@roundup.psfhosted.org> Tim Peters added the comment: Well, I have no code that would benefit from this change. What's the point? Sure, I use _parts_ of hash codes at times, but, e.g., index = the_hash_code & SOME_LOW_BIT_MASK in Python couldn't care less about the sign of `the_hash_code` - it returns a non-negative int regardless. The same applies if, e.g., SOME_LOW_BIT_MASK is `(1 << sys.hash_info.hash_bits) - 1`, giving a full-width non-negative hash without losing a bit of "entropy". But I've never felt a need for the latter. Likewise for doing, e.g., index = the_hash_code % SOME_POSITIVE_PRIME in Python. % takes the sign (positive here) of the modulus in Python. So this _looks_ like pointlessly disruptive code churn to me. What killer use case am I missing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 14:38:34 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 10 Aug 2019 18:38:34 +0000 Subject: [issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity In-Reply-To: <1565258224.48.0.98423013878.issue37792@roundup.psfhosted.org> Message-ID: <1565462314.13.0.535216127822.issue37792@roundup.psfhosted.org> Serhiy Storchaka added the comment: In some applications the order of attributes matters, and in others it does not. So the equality check is application dependent. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 14:46:32 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 10 Aug 2019 18:46:32 +0000 Subject: [issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity In-Reply-To: <1565258224.48.0.98423013878.issue37792@roundup.psfhosted.org> Message-ID: <1565462792.06.0.369831630026.issue37792@roundup.psfhosted.org> Stefan Behnel added the comment: Right. If you want to compare XML trees for equality, either write your own deep-tree comparison function, or use something like doctestcompare, or use a C14N serialisation (which is now part of Py3.8). Whichever suits your needs. https://github.com/lxml/lxml/blob/master/src/lxml/doctestcompare.py https://docs.python.org/3.8/library/xml.etree.elementtree.html#xml.etree.ElementTree.canonicalize ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 14:59:04 2019 From: report at bugs.python.org (Anthony Sottile) Date: Sat, 10 Aug 2019 18:59:04 +0000 Subject: [issue37810] ndiff reports incorrect location when diff strings contain tabs Message-ID: <1565463544.19.0.692436897534.issue37810@roundup.psfhosted.org> New submission from Anthony Sottile : Here's an example from difflib import ndiff def main(): x = '\tx\t=\ty\n\t \t \t^' y = '\tx\t=\ty\n\t \t \t^\n' print('\n'.join( line.rstrip('\n') for line in ndiff(x.splitlines(True), y.splitlines(True))) ) if __name__ == '__main__': exit(main()) Current output: $ python3.8 t.py x = y - ^ + ^ ? + Expected output: $ ./python t.py x = y - ^ + ^ ? + Found this while implementing a similar thing for flake8 here: https://gitlab.com/pycqa/flake8/merge_requests/339 and while debugging with pytest ---------- messages: 349353 nosy: Anthony Sottile priority: normal severity: normal status: open title: ndiff reports incorrect location when diff strings contain tabs versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 15:14:40 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Sat, 10 Aug 2019 19:14:40 +0000 Subject: [issue19692] Rename Py_SAFE_DOWNCAST In-Reply-To: <1385130295.49.0.846468108755.issue19692@psf.upfronthosting.co.za> Message-ID: <1565464480.95.0.269164765716.issue19692@roundup.psfhosted.org> Change by Sanyam Khurana : ---------- nosy: +CuriousLearner versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 15:36:09 2019 From: report at bugs.python.org (Anthony Sottile) Date: Sat, 10 Aug 2019 19:36:09 +0000 Subject: [issue37810] ndiff reports incorrect location when diff strings contain tabs In-Reply-To: <1565463544.19.0.692436897534.issue37810@roundup.psfhosted.org> Message-ID: <1565465769.55.0.603759501001.issue37810@roundup.psfhosted.org> Change by Anthony Sottile : ---------- keywords: +patch pull_requests: +14930 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15201 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 15:49:27 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Aug 2019 19:49:27 +0000 Subject: [issue37810] ndiff reports incorrect location when diff strings contain tabs In-Reply-To: <1565463544.19.0.692436897534.issue37810@roundup.psfhosted.org> Message-ID: <1565466567.95.0.0331583215369.issue37810@roundup.psfhosted.org> Raymond Hettinger added the comment: This seems like a reasonable suggestion to me. Am not sure whether it should be backported. Tim, what do you think? ---------- assignee: -> tim.peters components: +Library (Lib) nosy: +rhettinger, tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 16:19:29 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 10 Aug 2019 20:19:29 +0000 Subject: [issue37756] Error 0x80070643 when installing In-Reply-To: <1564932178.65.0.171539834023.issue37756@roundup.psfhosted.org> Message-ID: <1565468369.41.0.550902538386.issue37756@roundup.psfhosted.org> Steve Dower added the comment: I can't see anything specific in that log file, but if you can provide the "Python 3.7.4 (32-bit)_20190804181255_000_core_JustForMe.log" file, that should be able to help. (For others who may have to triage these in the future, the main thing you'll find in this log file is when the installer is attempting to upgrade from an AllUsers install to a JustForMe install, which almost always fails. But since this is upgrading from a previous JustForMe, it's not that.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 16:29:31 2019 From: report at bugs.python.org (Artem Khramov) Date: Sat, 10 Aug 2019 20:29:31 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) Message-ID: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> New submission from Artem Khramov : FreeBSD implementation of poll(2) restricts timeout argument to be either zero, or positive, or equal to INFTIM (-1). Unless otherwise overridden, socket timeout defaults to -1. This value is then converted to milliseconds (-1000) and used as argument to the poll syscall. poll returns EINVAL (22), and the connection fails. I have discovered this bug during the EINTR handling testing, and have naturally found a repro code in https://bugs.python.org/issue23618 (see connect_eintr.py, attached). On GNU/Linux, the example runs as expected. ---------- files: connect_eintr.py messages: 349356 nosy: akhramov priority: normal severity: normal status: open title: [FreeBSD, OSX] Socket module: incorrect usage of poll(2) versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file48537/connect_eintr.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 16:31:49 2019 From: report at bugs.python.org (Abhilash Raj) Date: Sat, 10 Aug 2019 20:31:49 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1565469109.76.0.0602453860809.issue34155@roundup.psfhosted.org> Abhilash Raj added the comment: Closing this since teh PRs are merged. ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 16:32:19 2019 From: report at bugs.python.org (Artem Khramov) Date: Sat, 10 Aug 2019 20:32:19 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) In-Reply-To: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> Message-ID: <1565469139.27.0.0745268062273.issue37811@roundup.psfhosted.org> Change by Artem Khramov : ---------- keywords: +patch pull_requests: +14931 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15202 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 16:32:47 2019 From: report at bugs.python.org (Abhilash Raj) Date: Sat, 10 Aug 2019 20:32:47 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565469167.33.0.537755297309.issue37764@roundup.psfhosted.org> Abhilash Raj added the comment: Adding security label since this can cause DOS. ---------- type: -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 17:07:30 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 10 Aug 2019 21:07:30 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) Message-ID: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> New submission from Greg Price : In longobject.c we have the following usage a few times: PyObject * PyLong_FromLong(long ival) { PyLongObject *v; // ... more locals ... CHECK_SMALL_INT(ival); if (ival < 0) { /* negate: can't write this as abs_ival = -ival since that invokes undefined behaviour when ival is LONG_MIN */ abs_ival = 0U-(unsigned long)ival; sign = -1; } else { // ... etc. etc. The CHECK_SMALL_INT macro contains a `return`, so the function can actually return before it reaches any of the other code. #define CHECK_SMALL_INT(ival) \ do if (-NSMALLNEGINTS <= ival && ival < NSMALLPOSINTS) { \ return get_small_int((sdigit)ival); \ } while(0) That's not even an error condition -- in fact it's the fast, hopefully reasonably-common, path. An implicit return like this is pretty surprising for the reader. And it only takes one more line (plus a close-brace) to make it explicit: if (IS_SMALL_INT(ival)) { return get_small_int((sdigit)ival); } so that seems like a much better trade. Patch written, will post shortly. ---------- components: Interpreter Core messages: 349359 nosy: Greg Price priority: normal severity: normal status: open title: Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 17:22:58 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 10 Aug 2019 21:22:58 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1565472178.63.0.301942616504.issue37812@roundup.psfhosted.org> Change by Greg Price : ---------- keywords: +patch pull_requests: +14932 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15203 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 17:31:48 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 10 Aug 2019 21:31:48 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1565472708.56.0.7990396725.issue37812@roundup.psfhosted.org> Greg Price added the comment: I've just sent GH-15203 which is the first of two patches for this. It's quite small. The second patch, which completes the change, is also small: https://github.com/gnprice/cpython/commit/c6b905104 It depends on the first one, so I think the easiest is for me to send it as a PR after the first is merged? Happy to do another workflow if that'd make review easier. (I don't see guidance in the devguide on handling a sequence of patches, so I'm making this up.) ---------- nosy: +aeros167, mark.dickinson, sir-sigurd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 17:34:14 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 10 Aug 2019 21:34:14 +0000 Subject: [issue37802] micro-optimization of PyLong_FromSize_t() In-Reply-To: <1565357260.71.0.37857302813.issue37802@roundup.psfhosted.org> Message-ID: <1565472854.58.0.418412204157.issue37802@roundup.psfhosted.org> Change by Greg Price : ---------- nosy: +Greg Price _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 17:46:12 2019 From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=) Date: Sat, 10 Aug 2019 21:46:12 +0000 Subject: [issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule Message-ID: <1565473572.7.0.81062665759.issue37813@roundup.psfhosted.org> New submission from G?ry : I have just read PEP 7 and noticed that its line-breaking recommandation in presence of binary operations seems to contradict its analogue in PEP 8 which follows Knuth's rule. PEP 7 (https://www.python.org/dev/peps/pep-0007/#code-lay-out): > When you break a long expression at a binary operator, the operator > goes at the end of the previous line, and braces should be formatted > as shown. E.g.: > > if (type->tp_dictoffset != 0 && base->tp_dictoffset == 0 && > type->tp_dictoffset == b_size && > (size_t)t_size == b_size + sizeof(PyObject *)) > { > return 0; /* "Forgive" adding a __dict__ only */ > } PEP 8 (https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator): > To solve this readability problem, mathematicians and their > publishers follow the opposite convention. Donald Knuth explains the > traditional rule in his Computers and Typesetting series: "Although > formulas within a paragraph always break after binary operations and > relations, displayed formulas always break before binary operations" > [3]. > > Following the tradition from mathematics usually results in more > readable code: > > # Yes: easy to match operators with operands > income = (gross_wages > + taxable_interest > + (dividends - qualified_dividends) > - ira_deduction > - student_loan_interest) > In Python code, it is permissible to break before or after a binary > operator, as long as the convention is consistent locally. For new > code Knuth's style is suggested. ---------- assignee: docs at python components: Documentation messages: 349361 nosy: docs at python, maggyero priority: normal severity: normal status: open title: PEP 7 line-breaking with binary operations contradicts Knuth's rule type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 18:04:32 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 Aug 2019 22:04:32 +0000 Subject: [issue37765] IDLE: Include keywords in __main__ autocomplete list In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org> Message-ID: <1565474672.0.0.9865449266.issue37765@roundup.psfhosted.org> Terry J. Reedy added the comment: After more research, I am more inclined to add the keywords to the global identifiers list. The IDLE doc says that they should be present. "Show Completions Open a scrollable list allowing selection of keywords and attributes." If this issue were rejected, the line above would have to be changed. (Other needed updates are another issue.) It was added to idlelib/help.txt (since replaced by help.html) by KBK in Revision: 209de1f6ca1beaaa6b5eeb413f02e9c8c334ee50 Author: Kurt B. Kaiser Date: 2/8/2007 5:58:18 PM Message: ... Added AutoComplete instructions to IDLE Help. (I checked 2.6 fetch_completions and keywords were not actually included in the global ('') list.) The completion menu entry was copied to idle.rst in patches for #5066 by Jessica McKeller and Todd Rovito. Both docs were updated. Another 5 people, at least, reviewed, including 3 core developers. It was committed by a 4th, Andrew Svetlov. So 9 people besides me did not notice the discrepancy and may have thought 'keywords, fine', like I have been. One can invoke Show Completions not following anything to get a list of names that one should not use. For that use, keywords should be included. This list currently has 230+ identifiers, 150+ all lowercase. keyword.kwlist would add 32 (35 - 3 builtins). It is not a huge increase. ---------- nosy: +cheryl.sabella stage: patch review -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 18:52:37 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 10 Aug 2019 22:52:37 +0000 Subject: [issue37765] IDLE: Include keywords in __main__ autocomplete list In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org> Message-ID: <1565477557.59.0.928329729329.issue37765@roundup.psfhosted.org> Raymond Hettinger added the comment: Since the word "main" is short and since the dunder prefix is common, I don't expect to get much value out of adding '__main__'. ISTM, this just increases the risk of a false positive for a given dunder method. > To be clear, I'm currently -1 on this suggestion. I concur. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 19:17:06 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 Aug 2019 23:17:06 +0000 Subject: [issue37756] Error 0x80070643 when installing In-Reply-To: <1564932178.65.0.171539834023.issue37756@roundup.psfhosted.org> Message-ID: <1565479026.86.0.304055322256.issue37756@roundup.psfhosted.org> Terry J. Reedy added the comment: I seems to me that Python Setup and Usage, Using Python on Windows should have a section for install failure and MS 0x8XXXXXXX install errors. Then I and others on python-list could tell people to start with that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 19:24:12 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 10 Aug 2019 23:24:12 +0000 Subject: [issue37765] IDLE: Include keywords in __main__ autocomplete list In-Reply-To: <1565028208.66.0.693944767751.issue37765@roundup.psfhosted.org> Message-ID: <1565479452.08.0.721125721202.issue37765@roundup.psfhosted.org> Terry J. Reedy added the comment: Raymond, since there is no proposal to 'add __main__', I don't understand your response. For the case in question, the completion list continues to be based on the keys in __main__.__builtins__.__dict__, and main__.__dict__, as it always has been. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 20:36:34 2019 From: report at bugs.python.org (Josh Holland) Date: Sun, 11 Aug 2019 00:36:34 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented Message-ID: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> New submission from Josh Holland : The empty tuple syntax in type annotations, `Tuple[()]`, is not obvious from the examples given in the documentation (I naively expected `Tuple[]` to work); it has been documented in PEP 484[1] and in mypy[2], but not in the documentation for the typing module. [1]: https://www.python.org/dev/peps/pep-0484/#the-typing-module [2]: https://github.com/python/mypy/pull/4313 ---------- assignee: docs at python components: Documentation messages: 349366 nosy: anowlcalledjosh, docs at python priority: normal severity: normal status: open title: typing module: empty tuple syntax is undocumented type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 20:42:33 2019 From: report at bugs.python.org (Missono Dell) Date: Sun, 11 Aug 2019 00:42:33 +0000 Subject: [issue37815] 'Make Test' error whe trying to install Python 3.7.4 on Linux Mint Message-ID: <1565484153.44.0.516842692215.issue37815@roundup.psfhosted.org> New submission from Missono Dell : Ran 38 tests in 1.058s FAILED (failures=1) test test_pdb failed 1 test failed again: test_pdb == Tests result: FAILURE then FAILURE == 403 tests OK. 1 test failed: test_pdb 12 tests skipped: test_devpoll test_kqueue test_msilib test_ossaudiodev test_startfile test_tix test_tk test_ttk_guionly test_winconsoleio test_winreg test_winsound test_zipfile64 1 re-run test: test_pdb Total duration: 6 min 5 sec Tests result: FAILURE then FAILURE Makefile:1076: recipe for target 'test' failed make: *** [test] Error 2 ---------- components: Installation messages: 349367 nosy: Missono Dell priority: normal severity: normal status: open title: 'Make Test' error whe trying to install Python 3.7.4 on Linux Mint type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 20:42:43 2019 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 11 Aug 2019 00:42:43 +0000 Subject: [issue16837] Number ABC can be instantiated In-Reply-To: <1357082763.61.0.378054227113.issue16837@psf.upfronthosting.co.za> Message-ID: <1565484163.83.0.225663560259.issue16837@roundup.psfhosted.org> Guido van Rossum added the comment: Let's not do this. We've survived this long. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 20:45:28 2019 From: report at bugs.python.org (Missono Dell) Date: Sun, 11 Aug 2019 00:45:28 +0000 Subject: [issue37815] 'Make Test' error while trying to install Python 3.7.4 on Linux Mint In-Reply-To: <1565484153.44.0.516842692215.issue37815@roundup.psfhosted.org> Message-ID: <1565484328.86.0.977952318929.issue37815@roundup.psfhosted.org> Missono Dell added the comment: Ran 38 tests in 1.058s FAILED (failures=1) test test_pdb failed 1 test failed again: test_pdb == Tests result: FAILURE then FAILURE == 403 tests OK. 1 test failed: test_pdb 12 tests skipped: test_devpoll test_kqueue test_msilib test_ossaudiodev test_startfile test_tix test_tk test_ttk_guionly test_winconsoleio test_winreg test_winsound test_zipfile64 1 re-run test: test_pdb Total duration: 6 min 5 sec Tests result: FAILURE then FAILURE Makefile:1076: recipe for target 'test' failed make: *** [test] Error 2 I can't finish installing Python with sudo make install because of this error ---------- title: 'Make Test' error whe trying to install Python 3.7.4 on Linux Mint -> 'Make Test' error while trying to install Python 3.7.4 on Linux Mint _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 21:06:41 2019 From: report at bugs.python.org (Glenn Linderman) Date: Sun, 11 Aug 2019 01:06:41 +0000 Subject: [issue37816] f-string documentation not fully accurate Message-ID: <1565485601.85.0.782571390413.issue37816@roundup.psfhosted.org> New submission from Glenn Linderman : I noticed the following description for f-strings: > Escape sequences are decoded like in ordinary string literals (except when a literal is also marked as a raw string). After decoding, the grammar for the contents of the string is: followed by lots of stuff, followed by > Backslashes are not allowed in format expressions and will raise an error: > f"newline: {ord('\n')}" # raises SyntaxError If f-strings are processed AS DESCRIBED, the \n would never seen by the format expression... but in fact, it does produce an error. PEP 498 has a more accurate description, that the {} parsing actually happens before the escape processing. The string or raw-string escape processing is done only to the literal string pieces. So the string content is first parsed for format expressions enclosed in {}, on the way, converting {{ and }} to { and } in the literal parts of the string, and then the literal parts are treated exactly like independent string literals (with regular or raw-string escaping performed), to be concatenated with the evaluation of the format expressions, and subsequent literal parts. The evaluation of the format expressions presently precludes the use of # and \ for comments and escapes, but otherwise tries to sort of by the same as a python expression possibly followed by a format mini-language part. I am not the expert here, just the messenger. ---------- assignee: docs at python components: Documentation messages: 349370 nosy: docs at python, v+python priority: normal severity: normal status: open title: f-string documentation not fully accurate versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 22:12:15 2019 From: report at bugs.python.org (Paul Martin) Date: Sun, 11 Aug 2019 02:12:15 +0000 Subject: [issue37817] create_pipe_connection and start_serving_pipe not documented Message-ID: <1565489535.63.0.517706154991.issue37817@roundup.psfhosted.org> New submission from Paul Martin : I found these two methods in the windows_events code for asyncio. Is there a reason why they don't seem to be documented, and are not included in AbstractServer? They provide a good Windows alternative to create_unix_server & create_unix_connection for inter-process communication. ---------- components: asyncio messages: 349371 nosy: asvetlov, primal, yselivanov priority: normal severity: normal status: open title: create_pipe_connection and start_serving_pipe not documented versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 22:54:30 2019 From: report at bugs.python.org (John Rogers) Date: Sun, 11 Aug 2019 02:54:30 +0000 Subject: [issue37818] Behaviors of binary bitwise operators contradicting documentation Message-ID: <1565492070.46.0.473056579761.issue37818@roundup.psfhosted.org> New submission from John Rogers : In Python Language Reference (version 3.7), section 6.9 it states that the arguments of binary bitwise operators must be integers. However, the following expressions work without error: True & False False | True True ^ True Each produces a boolean result (not integer) (False, True, False, respectively). Also I find that mixing booleans and integers does work too, though this time it produces integers. One can easily test it on Python home page's console window. I also tested it on my Linux box running version 3.5.3. So it appears that it has been overlooked for quite some time! As an aside: I do assume that boolean values are *distinct* from integers. If they are not, then my apologies! ---------- assignee: docs at python components: Documentation messages: 349372 nosy: The Blue Wizard, docs at python priority: normal severity: normal status: open title: Behaviors of binary bitwise operators contradicting documentation type: behavior versions: Python 3.5, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 23:03:08 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 03:03:08 +0000 Subject: [issue37759] Polish whatsnew for 3.8 In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org> Message-ID: <1565492588.68.0.707845744075.issue37759@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +14933 pull_request: https://github.com/python/cpython/pull/15204 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 23:17:56 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 11 Aug 2019 03:17:56 +0000 Subject: [issue37816] f-string documentation not fully accurate In-Reply-To: <1565485601.85.0.782571390413.issue37816@roundup.psfhosted.org> Message-ID: <1565493476.22.0.4022724257.issue37816@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 23:19:23 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 11 Aug 2019 03:19:23 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented In-Reply-To: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> Message-ID: <1565493563.34.0.511620991679.issue37814@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +gvanrossum, levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 23:43:43 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 11 Aug 2019 03:43:43 +0000 Subject: [issue37818] Behaviors of binary bitwise operators contradicting documentation In-Reply-To: <1565492070.46.0.473056579761.issue37818@roundup.psfhosted.org> Message-ID: <1565495023.83.0.477156209211.issue37818@roundup.psfhosted.org> Steven D'Aprano added the comment: bools are integers, specifically they are a subclass of int: py> isinstance(True, int) True py> issubclass(bool, int) True so the behaviour is correct. ---------- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 10 23:54:04 2019 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 11 Aug 2019 03:54:04 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented In-Reply-To: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> Message-ID: <1565495644.12.0.860916884703.issue37814@roundup.psfhosted.org> Guido van Rossum added the comment: That?s correct. Mind making a PR? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 01:18:54 2019 From: report at bugs.python.org (Zackery Spytz) Date: Sun, 11 Aug 2019 05:18:54 +0000 Subject: [issue37808] Deprecate unbound super methods In-Reply-To: <1565425079.51.0.763493261864.issue37808@roundup.psfhosted.org> Message-ID: <1565500734.3.0.158667791653.issue37808@roundup.psfhosted.org> Change by Zackery Spytz : ---------- keywords: +patch pull_requests: +14934 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15205 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 01:20:05 2019 From: report at bugs.python.org (Zackery Spytz) Date: Sun, 11 Aug 2019 05:20:05 +0000 Subject: [issue37808] Deprecate unbound super methods In-Reply-To: <1565425079.51.0.763493261864.issue37808@roundup.psfhosted.org> Message-ID: <1565500805.02.0.987519933153.issue37808@roundup.psfhosted.org> Change by Zackery Spytz : ---------- nosy: +ZackerySpytz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 02:01:19 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 06:01:19 +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: <1565503279.7.0.170649380919.issue15248@roundup.psfhosted.org> Raymond Hettinger added the comment: This isn't interacting well with IDLE. ==================================================== --- Works fine at the regular interactive prompt --- $ python3.8 Python 3.8.0b3 (v3.8.0b3:4336222407, Jul 29 2019, 09:46:03) [Clang 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> data = [ ... (1, 2, 3) # oops, missing comma! ... (4, 5, 6) ... ] :2: SyntaxWarning: 'tuple' object is not callable; perhaps you missed a comma? Traceback (most recent call last): File "", line 2, in ==================================================== --- Behaves differently in the IDLE Shell --- Python 3.8.0b3 (v3.8.0b3:4336222407, Jul 29 2019, 09:46:03) [Clang 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license()" for more information. >>> data = [ (1, 2, 3) # oops, missing comma! (4, 5, 6) ] SyntaxError: 'tuple' object is not callable; perhaps you missed a comma? ---------- assignee: docs at python -> terry.reedy components: +IDLE -Documentation nosy: +rhettinger status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 02:08:41 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 06:08:41 +0000 Subject: [issue16837] Number ABC can be instantiated In-Reply-To: <1357082763.61.0.378054227113.issue16837@psf.upfronthosting.co.za> Message-ID: <1565503721.23.0.160120689179.issue16837@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> wont fix stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 02:18:02 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 06:18:02 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1565504282.17.0.187832363748.issue37812@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks for the contribution Greg. I understand your reasoning but am going to decline PR 15203. Though the feature is not experimentnal, it is something we want be able to modify, shut-off, or extend at build time. Sometimes for testing we turn it off in order to identify identity test bugs. Also, eveonline was controlling this to save memory. ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 02:18:58 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 06:18:58 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1565504338.38.0.332050137093.issue37812@roundup.psfhosted.org> Raymond Hettinger added the comment: P.S. Making the returns explicit is a reasonable change to make, but the core #ifdef logic should remain. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 03:01:53 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 07:01:53 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() Message-ID: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> New submission from Raymond Hettinger : When working on Whatsnew3.8, I noticed that as_integer_ratio() had been added to ints and bools, was already present in floats and Decimals, but was missing from Fractions. IIRC, the goal was to make all of these have as a similar API so that x.as_integer_ratio() would work for all types that could support it (not complex numbers). ---------- components: Library (Lib) keywords: easy messages: 349378 nosy: lisroach, mark.dickinson, rhettinger priority: high severity: normal status: open title: as_integer_ratio() missing from fractions.Fraction() type: enhancement versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 03:17:44 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Sun, 11 Aug 2019 07:17:44 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1565507864.26.0.502657571011.issue37819@roundup.psfhosted.org> Change by Sanyam Khurana : ---------- nosy: +CuriousLearner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 04:06:28 2019 From: report at bugs.python.org (Greg Price) Date: Sun, 11 Aug 2019 08:06:28 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565504338.38.0.332050137093.issue37812@roundup.psfhosted.org> Message-ID: Greg Price added the comment: > Sometimes for testing we turn it off in order to identify identity test bugs. Interesting! Well, if the option is useful for testing, that's certainly a good reason to keep it. > Also, eveonline was controlling this to save memory. Also interesting. I feel like there must be something about their setup that I'm not imagining, because this is a pretty tiny amount of memory (9 kB) on the scale of a typical Python server process in my experience. Or do you mean they were increasing the numbers? One thought I had looking at this was actually that it would be interesting to do some measurements and try to pick new (default) values for these parameters - it looks like they're the same today as in 1993, and it's likely that with all that's changed in typical hardware since then (plus the switch from Python ints + longs to only what we used to call longs), the optimum values today are different from the optimum in 1993. And certainly one of the effects of this optimization when its hit rate is good is reducing memory consumption - you have only one 17 instead of however many you make. I'll rework the explicit-return patch to send without this change. It'll be a little trickier but should be entirely doable. On Sat, Aug 10, 2019, 23:19 Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > P.S. Making the returns explicit is a reasonable change to make, but the > core #ifdef logic should remain. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 04:17:31 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Aug 2019 08:17:31 +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: <1565511451.43.0.814880821328.issue15248@roundup.psfhosted.org> Serhiy Storchaka added the comment: I think it would be better to open a separate issue for IDLE. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 04:50:48 2019 From: report at bugs.python.org (hai shi) Date: Sun, 11 Aug 2019 08:50:48 +0000 Subject: [issue37496] Support annotations in signature strings. In-Reply-To: <1562197526.36.0.0415942737779.issue37496@roundup.psfhosted.org> Message-ID: <1565513448.04.0.164822200524.issue37496@roundup.psfhosted.org> Change by hai shi : ---------- nosy: +shihai1991 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 04:53:30 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 11 Aug 2019 08:53:30 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1565513610.82.0.540513073584.issue37819@roundup.psfhosted.org> Stefan Behnel added the comment: FWIW, makes total sense to me to have it there. Question is more if we can still get it into Py3.8, since it's a new feature for fractions. ---------- nosy: +lukasz.langa, scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 05:42:12 2019 From: report at bugs.python.org (hai shi) Date: Sun, 11 Aug 2019 09:42:12 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) In-Reply-To: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> Message-ID: <1565516532.29.0.711003728274.issue37811@roundup.psfhosted.org> hai shi added the comment: I found an OS distinguishing behavior in https://github.com/python/cpython/blob/master/Modules/selectmodule.c#L603-L612 ---------- nosy: +shihai1991 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 05:43:58 2019 From: report at bugs.python.org (Kubilay Kocak) Date: Sun, 11 Aug 2019 09:43:58 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) In-Reply-To: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> Message-ID: <1565516638.99.0.016026795881.issue37811@roundup.psfhosted.org> Change by Kubilay Kocak : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 05:47:38 2019 From: report at bugs.python.org (Kubilay Kocak) Date: Sun, 11 Aug 2019 09:47:38 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) In-Reply-To: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> Message-ID: <1565516858.72.0.229618805692.issue37811@roundup.psfhosted.org> Kubilay Kocak added the comment: See Also: #31334 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 07:08:32 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Sun, 11 Aug 2019 11:08:32 +0000 Subject: [issue26543] [EASY] imaplib noop Debug: bytes vs Unicode bug in debug mode In-Reply-To: <1457738623.54.0.0867122071018.issue26543@psf.upfronthosting.co.za> Message-ID: <1565521712.77.0.683149899669.issue26543@roundup.psfhosted.org> Change by Sanyam Khurana : ---------- pull_requests: +14935 pull_request: https://github.com/python/cpython/pull/15206 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 07:10:44 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 11 Aug 2019 11:10:44 +0000 Subject: [issue18766] IDLE: Autocomplete in editor doesn't work for un-imported modules In-Reply-To: <1376703586.47.0.0617094548794.issue18766@psf.upfronthosting.co.za> Message-ID: <1565521844.95.0.683765263953.issue18766@roundup.psfhosted.org> Tal Einat added the comment: I propose closing this as "wontfix", since this goes strongly against how completions currently work in IDLE (based on the namespace of the shell), and I don't think we're considering changing that. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 07:14:23 2019 From: report at bugs.python.org (Thrlwiti) Date: Sun, 11 Aug 2019 11:14:23 +0000 Subject: [issue18766] IDLE: Autocomplete in editor doesn't work for un-imported modules In-Reply-To: <1376703586.47.0.0617094548794.issue18766@psf.upfronthosting.co.za> Message-ID: <1565522063.1.0.461442231427.issue18766@roundup.psfhosted.org> Change by Thrlwiti : ---------- nosy: -THRlWiTi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 07:16:29 2019 From: report at bugs.python.org (Abdullah) Date: Sun, 11 Aug 2019 11:16:29 +0000 Subject: [issue37820] Unnecessary URL scheme exists to allow 'URL: reading file in urllib Message-ID: <1565522189.95.0.525978892849.issue37820@roundup.psfhosted.org> New submission from Abdullah : I am not sure if this was reported before, fixed, or even how to report this. However this issue is similar to https://bugs.python.org/issue35907 # Vulnerability PoC import urllib print urllib.urlopen('URL:/etc/passwd').read()[:30] the result is ## # User Database # # Note t I have tested the PoC on my Mac python 2.7. ---------- components: Library (Lib) messages: 349385 nosy: Alyan priority: normal severity: normal status: open title: Unnecessary URL scheme exists to allow 'URL: reading file in urllib type: security versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 07:17:08 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 11 Aug 2019 11:17:08 +0000 Subject: [issue37821] IDLE shell uses wrong namespace for completions Message-ID: <1565522228.88.0.811193115322.issue37821@roundup.psfhosted.org> New submission from Tal Einat : Currently, when running an IDLE shell with a sub-process, it will allow completing attributes of objects not actually in the shell's namespace. For example, typing "codecs." will bring up completions for the codecs module's attributes, despite that not having being imported. Further, if one uses the completion, this results in a NameError exception, since "codecs" isn't actually in the namespace. AFAICT, the intended behavior is as follows: * If a shell exists, completion should use the namespace used for evaluating code in the shell. (Note that this is slightly different when running a shell without a sub-process.) * If no shell exists (only editor windows are open), completion should use the global namespace + sys.modules. ---------- assignee: terry.reedy components: IDLE messages: 349386 nosy: taleinat, terry.reedy priority: normal severity: normal status: open title: IDLE shell uses wrong namespace for completions type: behavior versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 07:21:08 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 11 Aug 2019 11:21:08 +0000 Subject: [issue37821] IDLE shell uses wrong namespace for completions In-Reply-To: <1565522228.88.0.811193115322.issue37821@roundup.psfhosted.org> Message-ID: <1565522468.62.0.672128087376.issue37821@roundup.psfhosted.org> Change by Tal Einat : ---------- keywords: +patch pull_requests: +14936 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15207 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 07:22:02 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 11 Aug 2019 11:22:02 +0000 Subject: [issue37821] IDLE shell uses wrong namespace for completions In-Reply-To: <1565522228.88.0.811193115322.issue37821@roundup.psfhosted.org> Message-ID: <1565522522.97.0.611672238426.issue37821@roundup.psfhosted.org> Tal Einat added the comment: See fix in PR GH-15207. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 08:22:10 2019 From: report at bugs.python.org (Josh Holland) Date: Sun, 11 Aug 2019 12:22:10 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented In-Reply-To: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> Message-ID: <1565526130.55.0.916248337054.issue37814@roundup.psfhosted.org> Change by Josh Holland : ---------- keywords: +patch pull_requests: +14937 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15208 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 09:00:24 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Aug 2019 13:00:24 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented In-Reply-To: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> Message-ID: <1565528424.71.0.691936481599.issue37814@roundup.psfhosted.org> Serhiy Storchaka added the comment: What is better, Tuple[()] or Literal[()]? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 09:50:39 2019 From: report at bugs.python.org (Josh Holland) Date: Sun, 11 Aug 2019 13:50:39 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented In-Reply-To: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> Message-ID: <1565531439.3.0.316699724494.issue37814@roundup.psfhosted.org> Josh Holland added the comment: PEP 586 doesn't currently allow Literal to contain tuples, so Tuple[()] is the only option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 09:55:05 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Aug 2019 13:55:05 +0000 Subject: [issue37822] Add math.as_integer_ratio() Message-ID: <1565531705.4.0.857062617038.issue37822@roundup.psfhosted.org> New submission from Serhiy Storchaka : There are two interfaces to represent a number as a ratio. The numbers.Rational interface has two properties: numerator and denominator. float and Decimal do not support this interface, but they provide method as_integer_ratio() which return a 2-tuple (numerator, denominator). I propose to add math.as_integer_ratio() which unites both interfaces: uses the as_integer_ratio() method if it is defined, and uses the numerator and denominator properties otherwise. It will help in applications that work with exact numbers (e.g. modules fractions and statistics). ---------- components: Library (Lib) messages: 349390 nosy: mark.dickinson, rhettinger, serhiy.storchaka, stutzbach priority: normal severity: normal status: open title: Add math.as_integer_ratio() type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 09:57:28 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Aug 2019 13:57:28 +0000 Subject: [issue37822] Add math.as_integer_ratio() In-Reply-To: <1565531705.4.0.857062617038.issue37822@roundup.psfhosted.org> Message-ID: <1565531848.13.0.578301556428.issue37822@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +14938 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15210 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 10:11:54 2019 From: report at bugs.python.org (Anthony Sottile) Date: Sun, 11 Aug 2019 14:11:54 +0000 Subject: [issue37810] ndiff reports incorrect location when diff strings contain tabs In-Reply-To: <1565463544.19.0.692436897534.issue37810@roundup.psfhosted.org> Message-ID: <1565532714.87.0.949290469952.issue37810@roundup.psfhosted.org> Anthony Sottile added the comment: That's actually a good point, I don't think this should land in python3.7 since it changes outuput -- I'm removing that from the versions (though the bug does affect every version I have access to) ---------- versions: -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 11:22:29 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 11 Aug 2019 15:22:29 +0000 Subject: [issue23220] IDLE: Document how Shell displays user code output In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1565536949.31.0.314669045491.issue23220@roundup.psfhosted.org> Change by Tal Einat : ---------- pull_requests: +14939 pull_request: https://github.com/python/cpython/pull/15211 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 11:23:12 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 11 Aug 2019 15:23:12 +0000 Subject: [issue23220] IDLE: Document how Shell displays user code output In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1565536992.91.0.845400861404.issue23220@roundup.psfhosted.org> Tal Einat added the comment: See initial working implementation of handling \r and \b characters is the shell, PR GH-15211. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 12:13:29 2019 From: report at bugs.python.org (Mariatta) Date: Sun, 11 Aug 2019 16:13:29 +0000 Subject: [issue37823] Telnet documentation: fix the link to open() Message-ID: <1565540009.68.0.907395311638.issue37823@roundup.psfhosted.org> New submission from Mariatta : Bug in the Telnet docs: https://docs.python.org/3/library/telnetlib.html In the section https://docs.python.org/3/library/telnetlib.html#telnetlib.Telnet the ?open()? link should probably point to https://docs.python.org/3/library/telnetlib.html#telnetlib.Telnet.open but instead it points to https://docs.python.org/3/library/functions.html#open This is newcomer friendly and I would prefer it be done by first time contributors. Reported in docs mailing list: https://mail.python.org/pipermail/docs/2019-August/041817.html ---------- assignee: docs at python components: Documentation keywords: easy, newcomer friendly messages: 349393 nosy: Mariatta, docs at python priority: normal severity: normal stage: needs patch status: open title: Telnet documentation: fix the link to open() versions: Python 2.7, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 12:21:42 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Aug 2019 16:21:42 +0000 Subject: [issue34857] IDLE: SyntaxWarning not handled properly In-Reply-To: <1538338230.46.0.545547206417.issue34857@psf.upfronthosting.co.za> Message-ID: <1565540502.04.0.262880817204.issue34857@roundup.psfhosted.org> Serhiy Storchaka added the comment: I cannot reproduce this behavior in 3.7+. `assert (0, 'bad')` does not have any effect. But in 3.6 it outputs a traceback to the stderr. $ ./python -m idlelib Exception in Tkinter callback Traceback (most recent call last): File "/home/serhiy/py/cpython3.6/Lib/tkinter/__init__.py", line 1705, in __call__ return self.func(*args) File "/home/serhiy/py/cpython3.6/Lib/idlelib/multicall.py", line 176, in handler r = l[i](event) File "/home/serhiy/py/cpython3.6/Lib/idlelib/pyshell.py", line 1205, in enter_callback self.runit() File "/home/serhiy/py/cpython3.6/Lib/idlelib/pyshell.py", line 1246, in runit self.interp.runsource(line) File "/home/serhiy/py/cpython3.6/Lib/idlelib/pyshell.py", line 684, in runsource return InteractiveInterpreter.runsource(self, source, filename) File "/home/serhiy/py/cpython3.6/Lib/code.py", line 64, in runsource code = self.compile(source, filename, symbol) File "/home/serhiy/py/cpython3.6/Lib/codeop.py", line 168, in __call__ return _maybe_compile(self.compiler, source, filename, symbol) File "/home/serhiy/py/cpython3.6/Lib/codeop.py", line 82, in _maybe_compile code = compiler(source, filename, symbol) File "/home/serhiy/py/cpython3.6/Lib/codeop.py", line 133, in __call__ codeob = compile(source, filename, symbol, self.flags, 1) SyntaxWarning: assertion is always true, perhaps remove parentheses? But other syntax warnings are converted to errors in IDLE (reported by Raymond in https://bugs.python.org/issue15248#msg349375). In the regular interactive interpreter: >>> 0 is 0 :1: SyntaxWarning: "is" with a literal. Did you mean "=="? True >>> data = [ ... (1, 2, 3) # oops, missing comma! ... (4, 5, 6) ... ] :2: SyntaxWarning: 'tuple' object is not callable; perhaps you missed a comma? Traceback (most recent call last): File "", line 2, in TypeError: 'tuple' object is not callable In IDLE: >>> 0 is 0 SyntaxError: "is" with a literal. Did you mean "=="? >>> data = [ (1, 2, 3) # oops, missing comma! (4, 5, 6) ] SyntaxError: 'tuple' object is not callable; perhaps you missed a comma? ---------- nosy: +serhiy.storchaka versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 12:22:13 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Aug 2019 16:22:13 +0000 Subject: [issue34857] IDLE: SyntaxWarning not handled properly In-Reply-To: <1538338230.46.0.545547206417.issue34857@psf.upfronthosting.co.za> Message-ID: <1565540533.81.0.64097946007.issue34857@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 12:26:06 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Aug 2019 16:26:06 +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: <1565540766.74.0.620665950379.issue15248@roundup.psfhosted.org> Serhiy Storchaka added the comment: This is not related to this particular warning, but to how IDLE handles SyntaxWarning. See issue34857. ---------- assignee: terry.reedy -> components: +Interpreter Core -IDLE status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 12:32:12 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Aug 2019 16:32:12 +0000 Subject: [issue37824] IDLE: DeprecationWarning not handled properly Message-ID: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> New submission from Serhiy Storchaka : DeprecationWarning at compile time is output multiple times to the stderr (on console from which IDLE was ran), but not to IDLE Shell window. For example, when enter '\e': $ ./python -m idlelib Warning (from warnings module): File "", line 1 '\e' DeprecationWarning: invalid escape sequence \e >>> Warning (from warnings module): File "", line 1 '\e' DeprecationWarning: invalid escape sequence \e >>> Warning (from warnings module): File "", line 1 '\e' DeprecationWarning: invalid escape sequence \e And when close IDLE, additional output is printed in 3.8+: >>> Exception ignored in: Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/idlelib/run.py", line 488, in close File "/home/serhiy/py/cpython/Lib/idlelib/pyshell.py", line 1019, in close File "/home/serhiy/py/cpython/Lib/idlelib/editor.py", line 1058, in close File "/home/serhiy/py/cpython/Lib/idlelib/outwin.py", line 94, in maybesave File "/home/serhiy/py/cpython/Lib/idlelib/editor.py", line 991, in get_saved AttributeError: 'NoneType' object has no attribute 'get_saved' ---------- assignee: terry.reedy components: IDLE messages: 349396 nosy: serhiy.storchaka, terry.reedy priority: normal severity: normal status: open title: IDLE: DeprecationWarning not handled properly type: behavior versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 12:41:19 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 11 Aug 2019 16:41:19 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1565541679.8.0.734638334679.issue37819@roundup.psfhosted.org> Serhiy Storchaka added the comment: This will not solve the problem completely, because other rational numbers do not have as_integer_ratio(). But all rational numbers have the numerator and denominator properties. See issue37822 for more general solution. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 12:54:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 16:54:06 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1565542446.96.0.127037747689.issue37819@roundup.psfhosted.org> Raymond Hettinger added the comment: I think this can still go in for Fractions because it completes a feature that was already started (providing the method for the concrete types where it makes sense). Altering numbers.py can be saved for the future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 12:54:19 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 11 Aug 2019 16:54:19 +0000 Subject: [issue37825] IDLE doc improvements Message-ID: <1565542459.61.0.695168571425.issue37825@roundup.psfhosted.org> New submission from Terry J. Reedy : 1. Headings: Sections should be titlecased, subsections not. This is especially needed now that they are not numbered. 2. Python Shell subsection. Revise 'paste', maybe move. SyntaxWarnings are SyntaxErrors. Explain Restart. 3. Any other pending changes I include. ---------- assignee: terry.reedy components: IDLE messages: 349399 nosy: taleinat, terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE doc improvements versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 13:03:28 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 17:03:28 +0000 Subject: [issue37822] Add math.as_integer_ratio() In-Reply-To: <1565531705.4.0.857062617038.issue37822@roundup.psfhosted.org> Message-ID: <1565543008.9.0.764655336916.issue37822@roundup.psfhosted.org> Raymond Hettinger added the comment: -1 for having this spill into the math module. We're already started down a different path; otherwise, there would have been no need to add the as_integer_ratio method to int/bool. That was done so that x.as_integer_ratio() would work for all the concrete classes where it made sense. Right now, the only concrete class that is missing the method is Fractions. Adding it there is trivial and it doesn't garbage-up the math module with a pass-through function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 13:24:37 2019 From: report at bugs.python.org (Carol Willing) Date: Sun, 11 Aug 2019 17:24:37 +0000 Subject: [issue34985] python finds test modules from the wrong directory during PGO build In-Reply-To: <1539571414.02.0.788709270274.issue34985@psf.upfronthosting.co.za> Message-ID: <1565544277.26.0.127483760276.issue34985@roundup.psfhosted.org> Carol Willing added the comment: When building from the gzipped source of 3.8.0b3, I am seeing similar crashes on Ubuntu 18.04. Running ``make clean`` prior to ``configure`` and ``make`` seems to have resolved the issue. After this the regrtest was being found in the 3.8.0b3 directory. I am no longer seeing core dumps. I'm going to close this issue. ---------- nosy: +willingc resolution: -> not a bug stage: -> resolved status: open -> closed versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 13:38:02 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 17:38:02 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1565545082.34.0.2185197164.issue37819@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +14940 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15212 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 13:44:53 2019 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 11 Aug 2019 17:44:53 +0000 Subject: [issue37808] Deprecate unbound super methods In-Reply-To: <1565425079.51.0.763493261864.issue37808@roundup.psfhosted.org> Message-ID: <1565545493.4.0.325282437201.issue37808@roundup.psfhosted.org> Change by Guido van Rossum : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 13:53:40 2019 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 11 Aug 2019 17:53:40 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented In-Reply-To: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> Message-ID: <1565546020.28.0.300399745398.issue37814@roundup.psfhosted.org> Guido van Rossum added the comment: > What is better, Tuple[()] or Literal[()]? In this context, Tuple[()] is better, as the discussion is about how to write the type of various tuples. Tuple[()] is just the edge case of the type of the empty tuple. Josh, please sign the CLA and adjust the wording per my request in the PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 14:00:16 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 18:00:16 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1565546416.13.0.459340069261.issue37819@roundup.psfhosted.org> Raymond Hettinger added the comment: Guido, would you like to go forward with this? IIRC, you had decided that adding as_integer_ratio() to all the relevant concrete classes was the way to go. We already had the method on floats and Decimals, and then it was added bool and float, so Fraction is the only one missing. I believe the goal was to get x.as_integer_ratio() to run without type testing on all concrete numeric types that could support it. Serhiy is proposing to instead add a math.as_integer_ratio() function that would extract the components differently for different types (see issue 37822). If that had been our plan, then it was a mistake to add as_integer_ratio() to int and bool (as they already have numerator and denominator attributes). If you change you mind and want to go with 37822, we should probably rip-out the 3.8 addition to int and bool. Jeroen is proposing to down yet another path for this (see issue 28716). He wants to add a __ratio__ method to all the classes and access them with an operator.ratio() function. He thinks this will help the SageMath package. My recommendation is to stick with the original plan of adding the as_integer_ratio() to all the concrete types. The only one left to be done is in the Fractions module. That is pretty easy -- see PR 15212. There is some question about whether to change numbers.Rational() but that discussion can be left for another day -- concrete classes are allowed to have extra methods that aren't in the abstract classes. The abstract classes are harder to change because any existing user classes that had registered as Rational would instantly be non-compliant (though the fix is easy). I would like to get this finished up for 3.8. It doesn't make sense to me to have as_integer_ratio() for bool, int, float, and Decimal but to have omitted the most obvious case, Fraction. That defeats the purpose of having parallel APIs. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 14:16:53 2019 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 11 Aug 2019 18:16:53 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1565547413.0.0.810113271322.issue37819@roundup.psfhosted.org> Guido van Rossum added the comment: Let's continue on the current path -- add Fraction.as_integer_ratio(). Note that as_integer_ratio() is not part of the Numbers API, it is an optional protocol. You can count me out for Jeroen's __ratio__ proposal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 14:17:34 2019 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 11 Aug 2019 18:17:34 +0000 Subject: [issue37808] Deprecate unbound super methods In-Reply-To: <1565425079.51.0.763493261864.issue37808@roundup.psfhosted.org> Message-ID: <1565547454.9.0.614545163444.issue37808@roundup.psfhosted.org> Guido van Rossum added the comment: I don't have time to review this, sorry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 14:36:06 2019 From: report at bugs.python.org (Abhilash Raj) Date: Sun, 11 Aug 2019 18:36:06 +0000 Subject: [issue37826] Document PEP 3134 in tutorials/errors.rst Message-ID: <1565548566.46.0.213467869715.issue37826@roundup.psfhosted.org> New submission from Abhilash Raj : Looking at the docs, I couldn't find the `raise from` documentation anywhere in the Errors and Exceptions page (https://docs.python.org/3/tutorial/errors.html) page, which seems to be the landing page for Python Exceptions. I do see however that it is documented on the top page of https://docs.python.org/3/library/exceptions.html and raise statement's docs (https://docs.python.org/3/reference/simple_stmts.html#raise), both of which are pretty hard to discover. It would be nice to add the docs for `raise from` in the Errors and Exception page too. ---------- assignee: docs at python components: Documentation messages: 349406 nosy: docs at python, maxking priority: normal severity: normal status: open title: Document PEP 3134 in tutorials/errors.rst _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 16:45:15 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 11 Aug 2019 20:45:15 +0000 Subject: [issue32178] Some invalid email address groups cause an IndexError instead of a HeaderParseError In-Reply-To: <1512038434.94.0.213398074469.issue32178@psf.upfronthosting.co.za> Message-ID: <1565556315.74.0.0510741824434.issue32178@roundup.psfhosted.org> miss-islington added the comment: New changeset 09a1872a8007048dcdf825a476816c5e3498b8f8 by Miss Islington (bot) (Abhilash Raj) in branch 'master': bpo-32178: Fix IndexError trying to parse 'To' header starting with ':'. (GH-15044) https://github.com/python/cpython/commit/09a1872a8007048dcdf825a476816c5e3498b8f8 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 16:45:37 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 11 Aug 2019 20:45:37 +0000 Subject: [issue32178] Some invalid email address groups cause an IndexError instead of a HeaderParseError In-Reply-To: <1512038434.94.0.213398074469.issue32178@psf.upfronthosting.co.za> Message-ID: <1565556337.09.0.702608591633.issue32178@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14941 pull_request: https://github.com/python/cpython/pull/15213 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 16:45:44 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 11 Aug 2019 20:45:44 +0000 Subject: [issue32178] Some invalid email address groups cause an IndexError instead of a HeaderParseError In-Reply-To: <1512038434.94.0.213398074469.issue32178@psf.upfronthosting.co.za> Message-ID: <1565556344.33.0.216469346407.issue32178@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14942 pull_request: https://github.com/python/cpython/pull/15214 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 17:04:34 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 11 Aug 2019 21:04:34 +0000 Subject: [issue32178] Some invalid email address groups cause an IndexError instead of a HeaderParseError In-Reply-To: <1512038434.94.0.213398074469.issue32178@psf.upfronthosting.co.za> Message-ID: <1565557474.37.0.526619392072.issue32178@roundup.psfhosted.org> miss-islington added the comment: New changeset 9500bbe9372f6080decc49d2fd9365f0b927a0e2 by Miss Islington (bot) in branch '3.8': bpo-32178: Fix IndexError trying to parse 'To' header starting with ':'. (GH-15044) https://github.com/python/cpython/commit/9500bbe9372f6080decc49d2fd9365f0b927a0e2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 17:05:40 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 11 Aug 2019 21:05:40 +0000 Subject: [issue32178] Some invalid email address groups cause an IndexError instead of a HeaderParseError In-Reply-To: <1512038434.94.0.213398074469.issue32178@psf.upfronthosting.co.za> Message-ID: <1565557540.18.0.259855696657.issue32178@roundup.psfhosted.org> miss-islington added the comment: New changeset dec231a73c2a463b29f19c4e8357602c10a68856 by Miss Islington (bot) in branch '3.7': bpo-32178: Fix IndexError trying to parse 'To' header starting with ':'. (GH-15044) https://github.com/python/cpython/commit/dec231a73c2a463b29f19c4e8357602c10a68856 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 17:09:42 2019 From: report at bugs.python.org (Abhilash Raj) Date: Sun, 11 Aug 2019 21:09:42 +0000 Subject: [issue32178] Some invalid email address groups cause an IndexError instead of a HeaderParseError In-Reply-To: <1512038434.94.0.213398074469.issue32178@psf.upfronthosting.co.za> Message-ID: <1565557782.95.0.207081431409.issue32178@roundup.psfhosted.org> Change by Abhilash Raj : ---------- stage: patch review -> resolved status: open -> closed versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 17:11:13 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 21:11:13 +0000 Subject: [issue37822] Add math.as_integer_ratio() In-Reply-To: <1565531705.4.0.857062617038.issue37822@roundup.psfhosted.org> Message-ID: <1565557873.16.0.0726919027372.issue37822@roundup.psfhosted.org> Raymond Hettinger added the comment: Guido decided to stick with the current approach of adding as_integer_ratio() as needed to concrete classes. It is an optional API for user classes that register as numbers.Rational(). See https://bugs.python.org/msg349404 ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 17:41:02 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 21:41:02 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1565559662.61.0.803450994529.issue37819@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset f03b4c8a48f62134799d368b78da35301af466a3 by Raymond Hettinger in branch 'master': bpo-37819: Add Fraction.as_integer_ratio() (GH-15212) https://github.com/python/cpython/commit/f03b4c8a48f62134799d368b78da35301af466a3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 17:41:10 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 11 Aug 2019 21:41:10 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1565559670.81.0.207598239328.issue37819@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14943 pull_request: https://github.com/python/cpython/pull/15215 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 18:02:28 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 22:02:28 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1565560948.17.0.378960983152.issue37819@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 5ba1cb03939bd86d026db667580f590966b573ea by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-37819: Add Fraction.as_integer_ratio() (GH-15212) (GH-15215) https://github.com/python/cpython/commit/5ba1cb03939bd86d026db667580f590966b573ea ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 18:03:01 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 22:03:01 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1565560981.21.0.259441798064.issue37819@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 18:11:54 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 22:11:54 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1565561514.51.0.480086528531.issue37812@roundup.psfhosted.org> Raymond Hettinger added the comment: > I'll rework the explicit-return patch to send without this > change. It'll be a little trickier but should be entirely doable. An explicit return would be a nice improvement. On the other hand, if it is tricky and requires something more than minor surgery, that would be a hint that it isn't worth it. There is some value in code that is stable and known to be working just fine. See: https://en.wikipedia.org/wiki/There_are_known_knowns ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 18:27:11 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 22:27:11 +0000 Subject: [issue34632] Port importlib_metadata to Python 3.8 In-Reply-To: <1536689803.48.0.0269046726804.issue34632@psf.upfronthosting.co.za> Message-ID: <1565562431.02.0.183353164116.issue34632@roundup.psfhosted.org> Raymond Hettinger added the comment: Quick question: Is there a reason that requires() and files() return iterators instead of lists? ISTM that a list-based solution would be more usable than returning a starmap() object or somesuch. I suspect almost every user would have to call list(files(package)) rather than files(package). An iterator return type would only make sense if we need the values are produces lazily or if a known consumer required an iterator input. Also consider changing the parameter from files(package) to files(package_name). When I first tried-out this API, I typed: "import requests; files(requests)" instead of "files('requests')". Sorry to bring this up at a late stage, but the purpose of a beta release is to let other users try-out the API while there is still a chance to make adjustments. ---------- nosy: +rhettinger status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 19:09:59 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 11 Aug 2019 23:09:59 +0000 Subject: [issue34632] Port importlib_metadata to Python 3.8 In-Reply-To: <1536689803.48.0.0269046726804.issue34632@psf.upfronthosting.co.za> Message-ID: <1565564999.7.0.0443623688913.issue34632@roundup.psfhosted.org> Barry A. Warsaw added the comment: @jaraco will be able to answer that better than me. I actually thought those did return concrete lists. I also thought that the APIs accepted either a module or a package name, but maybe I'm thinking about importlib.resources. Again, @jaraco can clarify, but I think the problem is that there's no unambiguous mapping between packages and package names for metadata the way there is for resources. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 19:22:33 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 23:22:33 +0000 Subject: [issue34857] IDLE: SyntaxWarning not handled properly In-Reply-To: <1538338230.46.0.545547206417.issue34857@psf.upfronthosting.co.za> Message-ID: <1565565753.01.0.663664853379.issue34857@roundup.psfhosted.org> Raymond Hettinger added the comment: See: https://bugs.python.org/msg349375 Because new SyntaxWarnings were added in 3.8, I expect this problem to become more prevalent. Hopefully, this gets fixed for the 3.8 release. ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 19:30:32 2019 From: report at bugs.python.org (Greg Price) Date: Sun, 11 Aug 2019 23:30:32 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1565566232.12.0.383779265031.issue37812@roundup.psfhosted.org> Change by Greg Price : ---------- pull_requests: +14944 pull_request: https://github.com/python/cpython/pull/15216 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 19:32:09 2019 From: report at bugs.python.org (Greg Price) Date: Sun, 11 Aug 2019 23:32:09 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1565566329.75.0.278902437083.issue37812@roundup.psfhosted.org> Greg Price added the comment: > On the other hand, if it is tricky and requires something more than minor surgery, that would be a hint that it isn't worth it. There is some value in code that is stable and known to be working just fine. Definitely true! I think this change turned out quite clean, though. Just sent, as GH-15216 -- please take a look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 19:57:49 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 11 Aug 2019 23:57:49 +0000 Subject: [issue37807] Make hash() return a non-negative number In-Reply-To: <1565418246.0.0.695379140642.issue37807@roundup.psfhosted.org> Message-ID: <1565567869.83.0.439662983927.issue37807@roundup.psfhosted.org> Raymond Hettinger added the comment: > What killer use case am I missing? There's no killer use case. I just thought it weird that hte builtin hash() function ever returned a negative number. > This is a change of documented behaviour that will affect > 3rd party libraries that provide numeric types, like NumPy > and gmpy; it should not be done lightly. Okay, I'm happy to drop this. It was only a minor nuisance. Am not sure at what point we ever guaranteed that hash() would return negative numbers, or any particular number. That was probably a mistake. I thought the guarantees were all higher level metamorphic invariants such as hash(x) == hash(y) when x == y and {type(x), type(y)} ? {bool, int, float, Decimal, Fraction, complex}. BTW, I'm not sure why the numeric hashes are not getting all 64 bits in to play: from random import randrange, expovariate from secrets import token_hex, token_bytes for random_hash in [ lambda : hash(randrange(2**100)) % 2**64, lambda : abs(hash(expovariate(1.0))) % 2**64, lambda : hash(token_hex()) % 2**64, lambda : hash(token_bytes()) % 2**64, ]: print(max(random_hash().bit_length() for i in range(10_000))) Outputs: 61 61 64 64 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 20:13:09 2019 From: report at bugs.python.org (Ma Lin) Date: Mon, 12 Aug 2019 00:13:09 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1565568789.39.0.87218482043.issue37812@roundup.psfhosted.org> Ma Lin added the comment: How about using a hybrid implementation for `int`. For example, on 64-bit platform, if (a integer >=-9223372036854775808 and <=9223372036854775807), use a native `signed long` to represent it. People mostly use +-* operations, maybe using native int is faster, even including the cost of overflow checking. If operation will overflow or other operation like **, we can transform native int to current form and run in current code path. ---------- nosy: +Ma Lin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 20:27:51 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Mon, 12 Aug 2019 00:27:51 +0000 Subject: [issue34632] Port importlib_metadata to Python 3.8 In-Reply-To: <1536689803.48.0.0269046726804.issue34632@psf.upfronthosting.co.za> Message-ID: <1565569671.59.0.860538426745.issue34632@roundup.psfhosted.org> Jason R. Coombs added the comment: > Is there a reason that requires() and files() return iterators instead of lists? I'm a huge fan of `itertools` and Python 3's move to prefer iterables over materialized lists, and I feel that forcing materialized results gives the caller less control over the results. Following the same pattern that many standard Python objects return (`open`, `map`, `filter`), the approach is less constrained in that it can support arbitrarily large results. I wished to leave it to the caller to materialize a list if that was needed and my assumption was that 90% of the use-cases would be iterating over the results once. > I also thought that the APIs accepted either a module or a package name, Early on, I had hoped to have the API accept either the distribution package name or a Python package... and I even started creating a protocol for package vendors to provide a reference from their module or package back to the distribution package name. But I decided that approach was to invasive and unlikely to get widespread support, but also that it added little value. What importlib really works with is distribution packages (also known as Projects in PyPI) and not Python packages... and it works at an earlier abstraction (often you want to know metadata about a package without importing it). > Also consider changing the parameter from files(package) to files(package_name). I think at one point, the parameter name was distribution_name_or_package. We removed the acceptance of packages, but then renamed the parameter to 'package' for brevity. This parameter is used in many functions (files, requires, version, metadata, distribution). We'd want to change it in all of those. Once it becomes a parameter of the Distribution class (such as in Distribution.from_name), the 'distribution' is implied, so 'name' is clear enough. I do try to avoid long and multi-word parameters when possible. Perhaps more appropriate would be 'distribution_name' or 'dist_name'. I'm leaning toward 'dist_name' right now. What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 20:40:40 2019 From: report at bugs.python.org (Tim Peters) Date: Mon, 12 Aug 2019 00:40:40 +0000 Subject: [issue37807] Make hash() return a non-negative number In-Reply-To: <1565418246.0.0.695379140642.issue37807@roundup.psfhosted.org> Message-ID: <1565570440.61.0.139863913831.issue37807@roundup.psfhosted.org> Tim Peters added the comment: I agree: we "shouldn't have" documented anything about hash codes beyond the invariants needed to guarantee they work for their intended purpose, chiefly that x == y implies hash(x) == hash(y). Which leads to your other question ;-) That invariant is tricky to maintain across a pile of distinct but comparable numeric types! Whatever we return for an int needs also to be what's returned for a float that happens to have the same value, and whatever we return for a float needs also to be what's returned for a fraction.Fraction with the same value, and so on. So Python uses a single numeric hashing algorithm defined on mathematical rationals, described here: https://docs.python.org/3.8/library/stdtypes.html#hashing-of-numeric-types Presumably that's documented so that people defining their own numeric types have a clue about how to implement compatible hash codes. Anyway, that algorithm uses a large fixed prime P (different on 32- and 64-bit boxes), and uses operations modulo P. That's why the full bit width isn't used. And not just any prime P, it picks one for which computing the remainder mod P is especially efficient. 2**61 - 1 is as good as it gets on 64 bit boxes. I didn't pick this algorithm (I suspect Mark did), but I certainly approve of it. It's clever and general enough to apply to any plausible subset-of-real numeric type short of the constructive reals (where equality isn't even theoretically decidable, so "x == y implies ..." can't get off the ground ;-) ). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 20:52:13 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 12 Aug 2019 00:52:13 +0000 Subject: [issue34632] Port importlib_metadata to Python 3.8 In-Reply-To: <1536689803.48.0.0269046726804.issue34632@psf.upfronthosting.co.za> Message-ID: <1565571133.75.0.705184628525.issue34632@roundup.psfhosted.org> Raymond Hettinger added the comment: > Following the same pattern that many standard Python objects > return (`open`, `map`, `filter`), the approach is less > constrained in that it can support arbitrarily large results. > I wished to leave it to the caller to materialize a list if > that was needed and my assumption was that 90% of the use-cases > would be iterating over the results once. My recommendation is to return a concrete list. Shifting the responsibility to the user makes the API less convenient, particularly if someone is running this at the interactive prompt and just wants to see the results. We replaced the list version of map() with itertools.imap() for memory efficiency with potentially enormous or infinite inputs. However, this came at a cost for usability. In every single course where I present map() there is an immediate stumble over the need to wrap it in list() just to see the output. In general, we should save the iterators for cases where there is real value in lazy execution. Otherwise, usability, inspectability, sliceability, and re-iterability wins. (Just think of how awkward it would be if dir() or os.listdir() returned an iterator instead of a list.) FWIW, the doc string for requires() is: Return a list of requirements for the indicated distribution > Perhaps more appropriate would be 'distribution_name' or 'dist_name'. I recommend 'distribution_name'. It will normally be used as a positional parameter but the full name will show-up in the tool tips, providing guidance on how to use it. When you get a chance, please look at https://github.com/python/cpython/pull/15204 where I'm presenting your creation to the world. Overall, I think this was a nice addition to the standard library. Thanks for your work :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 20:54:24 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 12 Aug 2019 00:54:24 +0000 Subject: [issue37807] Make hash() return a non-negative number In-Reply-To: <1565418246.0.0.695379140642.issue37807@roundup.psfhosted.org> Message-ID: <1565571264.44.0.961307767043.issue37807@roundup.psfhosted.org> Raymond Hettinger added the comment: Withdrawing this issue and marking as closed. Thanks for your thoughts on the subject. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 21:13:35 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 12 Aug 2019 01:13:35 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1565572415.46.0.135745039768.issue37812@roundup.psfhosted.org> Raymond Hettinger added the comment: Ma Lin: Everything in Python is an object, nothing is native. There is room to reconsider the implementation of integer objects, known internally as PyLong objects. If you want to tease-out an alternative implementation, please do so on the python-ideas maillist. Small integer operations (including) indexing used to be smaller and faster in Python 2.7, so there is likely some room for improvement on what we have now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 21:16:16 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 12 Aug 2019 01:16:16 +0000 Subject: [issue37826] Document PEP 3134 in tutorials/errors.rst In-Reply-To: <1565548566.46.0.213467869715.issue37826@roundup.psfhosted.org> Message-ID: <1565572576.75.0.877763566313.issue37826@roundup.psfhosted.org> Raymond Hettinger added the comment: This is a reasonable suggestion. Would you like to submit a pull request? ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 21:44:21 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 Aug 2019 01:44:21 +0000 Subject: [issue37825] IDLE doc improvements In-Reply-To: <1565542459.61.0.695168571425.issue37825@roundup.psfhosted.org> Message-ID: <1565574261.64.0.24416644497.issue37825@roundup.psfhosted.org> Terry J. Reedy added the comment: Because the scope of SyntaxWarnings has been expanded to code that must be run, they should no longer be turned into errors, so this should not be added to the doc. See #34857. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 22:08:08 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Aug 2019 02:08:08 +0000 Subject: [issue37734] Registry keys for Windows Store package have wrong executable In-Reply-To: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org> Message-ID: <1565575688.53.0.793545978171.issue37734@roundup.psfhosted.org> Steve Dower added the comment: Here's an example of someone hitting this issue: https://stackoverflow.com/q/56974927 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 22:51:14 2019 From: report at bugs.python.org (Ma Lin) Date: Mon, 12 Aug 2019 02:51:14 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1565578274.17.0.289525270378.issue37812@roundup.psfhosted.org> Ma Lin added the comment: I sent twice, but it doesn't appear in Python-Ideas list. I will try to post to Python-Dev tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 23:11:01 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 12 Aug 2019 03:11:01 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1565579461.59.0.23346498782.issue37812@roundup.psfhosted.org> Raymond Hettinger added the comment: python-dev likely isn't the right place. That is a forum for more mature ideas. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 23:21:15 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 Aug 2019 03:21:15 +0000 Subject: [issue34857] IDLE: SyntaxWarning not handled properly In-Reply-To: <1538338230.46.0.545547206417.issue34857@psf.upfronthosting.co.za> Message-ID: <1565580075.83.0.74453437176.issue34857@roundup.psfhosted.org> Terry J. Reedy added the comment: Treating a SyntaxWarning as an error is intentional, since 2001 in a Kurt Kaiser patch. IDLE's ModifiedInterpreter subclasses code.InteractiveInterpreter. The subclass .runsource turns a SyntaxWarning into an error, before calling the superclass method, with warnings.filterwarnings(action="error", category=SyntaxWarning) As long as this is true, it should be documented. It is included in #37825. In interactive python (as opposed to IDLE), code is executed after a SyntaxWarning. In the non-callable call examples, minimally "()()", "[]()", "1()", and "''()", the result is a traceback that repeats the warning message. I think the repetition is mostly noise and is better omitted. I don't know what SyntaxWarnings were present in 2001, but I presume that Kurt had the same impression, whatever it or they were. The non-callable calls violate the 'ideal' Python grammar, which would have a production like "call = possible_callable '(', args, ')'. Violations are caught by the compiler rather than the parser. But they could plausibly be called a (subclass of) SyntaxError and execution avoided everywhere. The situation is quite different with "literal is (not) something", where 'literal' includes constant tuples. The expression is valid, normally runs without exception, and should be executed. To me, this is not a syntax issue, so SyntaxWarning seems wrong. But as long as is used for this situation, the conversion to error must cease. (If I knew how, I would prefer to still not call known non-callables in Shell.) There are two subcases with different reasons for pinging users. 1. The result is obvious ("0 is ''", "0 is ()") and unchanged when 'is' is replaced with '=='. The advice is useless. It should instead, it seems to me, be to use True or False. I suspect that this case is rare. 2. The result using 'is' is implementation dependent ("0 is 0", "0 is a", "1000 is 1000"). For production code, the advice to change 'is' to '==' is correct. For exploration of 'is' in a shell, which many beginners like to do, it likely is not, at least not immediately. -- My initial messsage above is moot since compile("assert (0, 'bad')", '', 'single') no longer emit a SyntaxWarning, and the new warnings do not show the same behavior, even for similarly legal code such as "0 is 0". My second message, about when a SyntaxWarning for a file is displayed, is still relevant, and I agree that it is a higher priority than before. But it is more complex than reported above. First, there are other warnings than SyntaxWarning, and we might decide to optionally enable them. Second, Run Module does Check Module first. If Check Module is selected directly, there is no restart line. Third, there will be no restart line if there is a SyntaxError, or a Tabnanny but there might be prior warnings. I think I know how to deal with all of the above. Module SyntaxErrors and Tabnanny errors are displayed in a popup error box, with the cursor moved to the line and maybe column of the error. Warnings could be put in a separate box unless there is a restart. I would prefer to not shift focus to Shell unless and until a module is run. ---------- priority: high -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 23:21:28 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 Aug 2019 03:21:28 +0000 Subject: [issue34857] IDLE: SyntaxWarning not handled properly In-Reply-To: <1538338230.46.0.545547206417.issue34857@psf.upfronthosting.co.za> Message-ID: <1565580088.3.0.19785463546.issue34857@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 11 23:38:14 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 Aug 2019 03:38:14 +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: <1565581094.67.0.0756946367496.issue15248@roundup.psfhosted.org> Terry J. Reedy added the comment: IDLE's Shell has treated SyntaxWarnings as errors since 2001. I don't know if any other IDE's do the same. Raymond's example did not concern me, as I think not calling known non-callables is preferable. But not executing literal-with-is code, such as "a = 1; a is 1" and "0 is ''" is wrong. See msg349431 of #34857 for more discussion of these cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 00:00:56 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 Aug 2019 04:00:56 +0000 Subject: [issue18766] IDLE: Autocomplete in editor doesn't work for un-imported modules In-Reply-To: <1376703586.47.0.0617094548794.issue18766@psf.upfronthosting.co.za> Message-ID: <1565582456.95.0.909350343976.issue18766@roundup.psfhosted.org> Terry J. Reedy added the comment: The import-on-demand would be executed in the Shell's execution process namespace, so it works with the current implementation. I said above that this puts names 'where they don't belong', but I feel a little differently now. A variant idea might be to execute all imports as entered in the editor in the shell. A pie-in-the-sky idea is to give each editor its own execution process and execute each line as entered, or something like that. But I have put off researching what other editors do until we get what we have working better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 00:17:19 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 12 Aug 2019 04:17:19 +0000 Subject: [issue34857] IDLE: SyntaxWarning not handled properly In-Reply-To: <1538338230.46.0.545547206417.issue34857@psf.upfronthosting.co.za> Message-ID: <1565583439.87.0.650421205232.issue34857@roundup.psfhosted.org> Raymond Hettinger added the comment: Terry, thanks for the thorough analysis and explanation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 00:18:54 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 Aug 2019 04:18:54 +0000 Subject: [issue37825] IDLE doc improvements In-Reply-To: <1565542459.61.0.695168571425.issue37825@roundup.psfhosted.org> Message-ID: <1565583534.96.0.601134106014.issue37825@roundup.psfhosted.org> Terry J. Reedy added the comment: 4. Completions subsection: fix this garbled sentence. "Names in an Editor window which are not via __main__ and sys.modules will not be found." Check 2.6 help.txt from whence it likely came. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 00:26:09 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 Aug 2019 04:26:09 +0000 Subject: [issue37825] IDLE doc improvements In-Reply-To: <1565542459.61.0.695168571425.issue37825@roundup.psfhosted.org> Message-ID: <1565583969.35.0.308252706524.issue37825@roundup.psfhosted.org> Terry J. Reedy added the comment: The garble was in help.txt as copied into idle.rst in #5066. I will have to figure out the meaning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 01:10:11 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 Aug 2019 05:10:11 +0000 Subject: [issue37821] IDLE shell uses wrong namespace for completions In-Reply-To: <1565522228.88.0.811193115322.issue37821@roundup.psfhosted.org> Message-ID: <1565586611.64.0.973161953384.issue37821@roundup.psfhosted.org> Terry J. Reedy added the comment: I think the current behavior is intended. The IDLE doc Completions subsection, written by Kurt Kaiser in help.text and copied to idle.rst in #5066, has this paragraph Completions are currently limited to those in the namespaces. Names in an Editor window which are not via __main__ and sys.modules will not be found. Run the module once with your imports to correct this situation. Note that IDLE itself places quite a few modules in sys.modules, so much can be found by default, e.g. the re module." The second sentence is garbled but says that things in sys.modules *will* be found. The fourth sentence points out that sys.modules has many things imported by IDLE, not by user code, so they can be found *without running one's code*. The example is "import re...re." and re completions pop up. I noted on #18766 that cleaning up run.py made this *feature* less useful. It appears that this issue and your patch are about disable this intended feature. I don't agree. To put it another way, "If a shell exists, completion should use the namespace used for evaluating code in the shell." is not correct. The intended behavior is to complete if at all possible. #18766 is about expanding 'possible'. To constantly maximize 'possible', one would run after every name-binding statement (an extreme version of the 3rd sentence above). I sometimes come close to that, though more to catch typos and rerun tests as I go. You are correct that entering 're.DOTALL' by completion without also entering the required corresponding import results in a NameError when running the code . But the same is true if one enters the same 're.DOTALL' by key. Either way, one has entered the attribute where and when wanted; the NameError says "now go back up and add the import". What is odd to me is that you seem happy using the more numerous non-user IDLE imports when there is no Shell. That would mean that users would initially be better off killing the shell when starting to edit. To me, the logic of restricting completions when there is a shell would mean no completions when there is not. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 01:28:15 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 Aug 2019 05:28:15 +0000 Subject: [issue23220] IDLE: Document how Shell displays user code output In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1565587695.39.0.894162572977.issue23220@roundup.psfhosted.org> Terry J. Reedy added the comment: The conclusion of this discussion was that we should insert control chars, in particular \b and \r, as are into tk.Text and document the (variable) result. Please describe your proposed new behavior, how it differs from the current behavior, and why you think it better. I think that this should be a new issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 01:38:23 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 Aug 2019 05:38:23 +0000 Subject: [issue35263] Add None handling for get_saved() in IDLE In-Reply-To: <1542349566.92.0.788709270274.issue35263@psf.upfronthosting.co.za> Message-ID: <1565588303.9.0.540090482416.issue35263@roundup.psfhosted.org> Terry J. Reedy added the comment: I suspect that this is related to #35379, where I added some preliminary analysis. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 02:52:53 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 12 Aug 2019 06:52:53 +0000 Subject: [issue37827] IDLE: Have the shell mimic terminal handling of \r and \b control characters in outputs Message-ID: <1565592773.8.0.657523892243.issue37827@roundup.psfhosted.org> New submission from Tal Einat : IDLE's shell doesn't currently handle \r and \b in any special way; they are written the the Tk Text widget which displays them in strange, system-dependent ways. These are often used to show continuously updated progress, e.g. in text-based progress bars, without flooding the output, since they allow overwriting previously written output. If we implement handling for \r and \b, progress indicators such as these could finally work properly in IDLE's shell. To make things worse, Tk's Text widget becomes increasingly slow when it wraps very long lines. IDLE's shell must wrap lines, and is therefore prone to such slowdowns. Attempting to show updating progress info using \r or \b results in such increasingly long lines of output, eventually slowing IDLE's shell down to a crawl. (The recent addition of squeezing of long outputs help for the case of single, very long outputs, but not with many short strings written on a single line.) As a recent example, the basic Tensorflow tutorial shows such progress information for several of its stages. Due to the lack of handling for these control characters, it is practically unusable in the IDLE shell due to this. See issue #37762 about this. Since the shell aims to closely emulate using an interactive terminal session, and since showing progress is so common in interactive work, I propose to add special handling of these two control characters in outputs written to the shell window. Related issues: #23220: Documents input/output effects of how IDLE runs user code (originally titled "IDLE does not display \b backspace correctly") #24572: IDLE Text Output With ASCII Control Codes Not Working (marked as duplicate of #23220) #37762: IDLE very slow due a super long line output in chunks StackOverflow: what is the difference between cmd and idle when using tqdm? (https://stackoverflow.com/questions/35895864/what-is-the-difference-between-cmd-and-idle-when-using-tqdm) ---------- assignee: terry.reedy components: IDLE messages: 349440 nosy: cheryl.sabella, rhettinger, taleinat, terry.reedy priority: normal severity: normal status: open title: IDLE: Have the shell mimic terminal handling of \r and \b control characters in outputs type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 02:54:09 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 12 Aug 2019 06:54:09 +0000 Subject: [issue37827] IDLE: Have the shell mimic terminal handling of \r and \b control characters in outputs In-Reply-To: <1565592773.8.0.657523892243.issue37827@roundup.psfhosted.org> Message-ID: <1565592849.4.0.586181316165.issue37827@roundup.psfhosted.org> Change by Tal Einat : ---------- keywords: +patch pull_requests: +14945 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15211 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 02:58:00 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 12 Aug 2019 06:58:00 +0000 Subject: [issue37824] IDLE: DeprecationWarning not handled properly In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1565593080.45.0.376660624245.issue37824@roundup.psfhosted.org> Terry J. Reedy added the comment: None.get_saved is #35623. I believe it is related to #35379, where I requested your comment on what I found so far. --- 1. Compiler warnings for shell input go to sys.__stderr, which only exists when IDLE is started from a console. This will include SyntaxWarnings when not turned into errors. pyshell 67+, warning_stream and idle_showwarning. I have no idea why. Compiler warnings for editor contents and runtime warnings go to shell. For now, all should go to Shell. 2. Warnings are formatted by run 42, idle_formatwarning. Someone must have decided that ":1: DeprecationWarning: invalid escape sequence \e" is newbie unfriendly. When printed in an editor-derived window, the IDLE format will enable context menu 'goto file/line'. But 4 lines is a lot and the top line only serves to imitate the 'Traceback ...' line. I will think about this. Perhaps DeprecationWarning: invalid escape sequence \e File "", line 1 '\e' 3. Warnings (at least this one) for shell input are printed 3 times. I do not know why at present. ModifiedInterpreter.runsource calls code.InteractiveInterpreter(self, source, filename (pyshell 669). Perhaps the latter is buggy in somehow calling compile 3 times. I will look another time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 02:59:33 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 12 Aug 2019 06:59:33 +0000 Subject: [issue23220] IDLE: Document how Shell displays user code output In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1565593173.05.0.37700606301.issue23220@roundup.psfhosted.org> Tal Einat added the comment: Ah, sorry for missing that, Terry. See new issue, #37827, for the proposed change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 03:00:02 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 12 Aug 2019 07:00:02 +0000 Subject: [issue37827] IDLE: Have the shell mimic terminal handling of \r and \b control characters in outputs In-Reply-To: <1565592773.8.0.657523892243.issue37827@roundup.psfhosted.org> Message-ID: <1565593202.1.0.000783255723022.issue37827@roundup.psfhosted.org> Tal Einat added the comment: See PR GH-15211 with a working implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 03:00:43 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 12 Aug 2019 07:00:43 +0000 Subject: [issue23220] IDLE: Document how Shell displays user code output In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za> Message-ID: <1565593243.65.0.871843896396.issue23220@roundup.psfhosted.org> Change by Tal Einat : ---------- pull_requests: -14939 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 03:12:33 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 12 Aug 2019 07:12:33 +0000 Subject: [issue37828] Fix default mock_name in unittest.mock.assert_called error message Message-ID: <1565593953.82.0.916439327482.issue37828@roundup.psfhosted.org> New submission from Karthikeyan Singaravelan : In the format string for assert_called the evaluation order is incorrect and hence for mock's without name 'None' is printed whereas it should be 'mock' like for other messages. The error message is ("Expected '%s' to have been called." % self._mock_name or 'mock') . Here self._mock_name which is None is applied to form the string and then used with the string 'mock' in or combination. The fix would be to have the evaluation order correct like other error messages. Marking this as newcomer-friendly. Please leave this to new contributors as their 1st PR. ./python.exe Python 3.9.0a0 (heads/master:f03b4c8a48, Aug 12 2019, 10:04:10) [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.assert_called_once() Traceback (most recent call last): File "", line 1, in File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py", line 854, in assert_called_once raise AssertionError(msg) AssertionError: Expected 'mock' to have been called once. Called 0 times. >>> m.assert_called() Traceback (most recent call last): File "", line 1, in File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py", line 844, in assert_called raise AssertionError(msg) AssertionError: Expected 'None' to have been called. Thanks ---------- components: Library (Lib) keywords: newcomer friendly messages: 349444 nosy: cjw296, mariocj89, michael.foord, xtreak priority: normal severity: normal status: open title: Fix default mock_name in unittest.mock.assert_called error message type: behavior versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 04:16:05 2019 From: report at bugs.python.org (Jakub Kulik) Date: Mon, 12 Aug 2019 08:16:05 +0000 Subject: [issue37785] argparse uses %s in gettext calls causing xgettext warnings In-Reply-To: <1565182156.22.0.512922989842.issue37785@roundup.psfhosted.org> Message-ID: <1565597765.69.0.0299390095599.issue37785@roundup.psfhosted.org> Jakub Kulik added the comment: Thanks, I see; this is not a change for security only stage. I merged your suggestion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 04:25:59 2019 From: report at bugs.python.org (pasenor) Date: Mon, 12 Aug 2019 08:25:59 +0000 Subject: [issue37829] Documentation of stdlib: add example of mixed arguments to dict() Message-ID: <1565598359.42.0.652909866188.issue37829@roundup.psfhosted.org> New submission from pasenor : The following use of the dict() function with both positional and keyword arguments does follow from the description, but probably needs it's own example: dict({'a': 1}, b=2}) == {'a': 1, 'b': 2} ---------- assignee: docs at python components: Documentation messages: 349446 nosy: docs at python, pasenor priority: normal severity: normal status: open title: Documentation of stdlib: add example of mixed arguments to dict() versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 04:33:31 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Mon, 12 Aug 2019 08:33:31 +0000 Subject: [issue37822] Add math.as_integer_ratio() In-Reply-To: <1565531705.4.0.857062617038.issue37822@roundup.psfhosted.org> Message-ID: <1565598811.41.0.523776564123.issue37822@roundup.psfhosted.org> Jeroen Demeyer added the comment: Aren't you worried about using the non-special non-reserved attributes like "as_integer_ratio"? That's the reason why I proposed a dunder name "__ratio__" instead of "as_integer_ratio". In my opinion, it was a mistake in PEP 3141 to use non-reserved names like "numerator" and "denominator" because they might already be used by existing classes with a different meaning (this is precisely what happened with SageMath). It's an honest question. If you say, "we thought about it and think it's just fine to use as_integer_ratio()", just say so and that's fine for me. ---------- nosy: +jdemeyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 04:37:08 2019 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 12 Aug 2019 08:37:08 +0000 Subject: [issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores. In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org> Message-ID: <1565599028.45.0.356883621339.issue37751@roundup.psfhosted.org> Marc-Andre Lemburg added the comment: Jordon is right. Conversion has to be to underscores, not hyphens. I guess this bug was introduced when the normalization function was converted to C. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 04:40:28 2019 From: report at bugs.python.org (pasenor) Date: Mon, 12 Aug 2019 08:40:28 +0000 Subject: [issue37829] Documentation of stdlib: add example of mixed arguments to dict() In-Reply-To: <1565598359.42.0.652909866188.issue37829@roundup.psfhosted.org> Message-ID: <1565599228.26.0.38249125402.issue37829@roundup.psfhosted.org> Change by pasenor : ---------- keywords: +patch pull_requests: +14946 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15220 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 04:55:55 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Mon, 12 Aug 2019 08:55:55 +0000 Subject: [issue37785] argparse uses %s in gettext calls causing xgettext warnings In-Reply-To: <1565182156.22.0.512922989842.issue37785@roundup.psfhosted.org> Message-ID: <1565600155.47.0.0108968538397.issue37785@roundup.psfhosted.org> Sanyam Khurana added the comment: Hi Eric, This is with reference to https://bugs.python.org/issue10528. I've looked at the PR and it's ready for a core-review: https://github.com/python/cpython/pull/15161 Can you please take a look at this? Many thanks! ---------- nosy: +bethard, eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 05:33:33 2019 From: report at bugs.python.org (Batuhan) Date: Mon, 12 Aug 2019 09:33:33 +0000 Subject: [issue37830] continue in finally with return in try results with segfault Message-ID: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> New submission from Batuhan : When you try to put a return statement with the iterated value inside of try/finally and if you have continue in finally it will result with segfault. def simple(): for number in range(2): try: return number finally: continue simple() SEGV My first debugs shows TOS is the next value int(1) when it comes to FOR_ITER, instead of the range instance. So when python try to call next() with (*iter->ob_type->tp_iternext)(iter) in FOR_ITER it gets a non iterator, int(1). Adding an assert can prove it, python: Python/ceval.c:3198: _PyEval_EvalFrameDefault: Assertion `PyIter_Check(iter)' failed. For seeing how stack changed i enabled lltrace and formatted it little bit; >>> STACK_SIZE 0 LOAD_GLOBAL 0 >>> STACK_SIZE 0 >>> push LOAD_CONST 1 >>> STACK_SIZE 1 >>> push 2 CALL_FUNCTION 1 >>> STACK_SIZE 2 >>> ext_pop 2 >>> ext_pop >>> push range(0, 2) GET_ITER None >>> STACK_SIZE 1 FOR_ITER 24 >>> STACK_SIZE 1 >>> push 0 STORE_FAST 0 >>> STACK_SIZE 2 >>> pop 0 SETUP_FINALLY 12 >>> STACK_SIZE 1 LOAD_FAST 0 >>> STACK_SIZE 1 >>> push 0 POP_BLOCK None >>> STACK_SIZE 2 CALL_FINALLY 6 >>> STACK_SIZE 2 >>> push 20 POP_FINALLY 0 >>> STACK_SIZE 3 >>> pop 20 JUMP_ABSOLUTE 8 >>> STACK_SIZE 2 FOR_ITER 24 >>> STACK_SIZE 2 [SEGV] And the oddity is STACK_SIZE should be 1 before the FOR_ITER but it is 2, then i said why dont i try the SECOND() as iter, and it worked. It means an instruction is pushing the value of previous iteration. There are 3 things we can do; => raise a RuntimeError if TOS isn't an iterator (IMHO we should do that) => check if try/finally created inside of a function and an iterator. then check inside of try if a return happens with the iterated value and if so set preserve_tos value to false. => dont allow continue in finally I want to fix this, and i prefer the first one. If you have any suggestion, i am open. ---------- messages: 349450 nosy: BTaskaya priority: normal severity: normal status: open title: continue in finally with return in try results with segfault _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 05:36:56 2019 From: report at bugs.python.org (Batuhan) Date: Mon, 12 Aug 2019 09:36:56 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565602616.46.0.015202930228.issue37830@roundup.psfhosted.org> Change by Batuhan : ---------- keywords: +patch pull_requests: +14948 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15221 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 05:57:35 2019 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 12 Aug 2019 09:57:35 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565603855.64.0.965652386746.issue37830@roundup.psfhosted.org> Change by Eric V. Smith : ---------- components: +Interpreter Core type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 05:57:51 2019 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 12 Aug 2019 09:57:51 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565603871.1.0.269439454711.issue37830@roundup.psfhosted.org> Change by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 06:09:45 2019 From: report at bugs.python.org (Batuhan) Date: Mon, 12 Aug 2019 10:09:45 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565604585.28.0.678084166841.issue37830@roundup.psfhosted.org> Change by Batuhan : ---------- versions: +Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 06:26:02 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 12 Aug 2019 10:26:02 +0000 Subject: [issue37785] argparse uses %s in gettext calls causing xgettext warnings In-Reply-To: <1565182156.22.0.512922989842.issue37785@roundup.psfhosted.org> Message-ID: <1565605562.46.0.680771263703.issue37785@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 06:28:03 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 12 Aug 2019 10:28:03 +0000 Subject: [issue37829] Documentation of stdlib: add example of mixed arguments to dict() In-Reply-To: <1565598359.42.0.652909866188.issue37829@roundup.psfhosted.org> Message-ID: <1565605683.23.0.0982409297035.issue37829@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +inada.naoki, rhettinger versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 06:34:52 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Mon, 12 Aug 2019 10:34:52 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565606092.41.0.39674742916.issue37830@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Adding Serhiy since this change was introduced with issue32489. ---------- nosy: +serhiy.storchaka, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 06:48:52 2019 From: report at bugs.python.org (Tomer Vromen) Date: Mon, 12 Aug 2019 10:48:52 +0000 Subject: [issue37831] bool(~True) == True Message-ID: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> New submission from Tomer Vromen : Bitwise operators have inconsistent behavior when acting on bool values: (Python 3.7.4) # "&" works like "and" >>> True & True True >>> True & False False >>> False & False False # "|" works like "or" >>> True | True True >>> True | False True >>> False | False False # "~" does not work like "not"! >>> ~True -2 >>> ~False -1 The result of this is the a user might start working with "&" and "|" on bool values (for whatever reason) and it will work as expected. But then, when adding "~" to the mix, things start to break. The proposal is to make "~" act like "not" on bool values, i.e. ~True will be False; ~False will be True. I'm not sure if this has any negative impact on existing code. I don't expect any, but you can never know. If there is no objection to this change, I can even try to implement it myself an submit a patch. ---------- components: Interpreter Core messages: 349452 nosy: tomerv priority: normal severity: normal status: open title: bool(~True) == True type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 07:00:50 2019 From: report at bugs.python.org (Jeffrey Walton) Date: Mon, 12 Aug 2019 11:00:50 +0000 Subject: [issue37832] _Py_HashRandomization_Init: failed to get random numbers Message-ID: <1565607650.45.0.0402326097483.issue37832@roundup.psfhosted.org> New submission from Jeffrey Walton : I need to setup a Debian HURD test machine to investigate a problem I was seeing in the Crypto++ library. After setting up the machine and running an apt-get install for some build tools I noticed Python was failing: Fatal Python error: _Py_HashRandomization_Init: failed to get random numbers to initialize Python It seems HURD no longer provides /dev/urandom out of the box. This is new behavior, and it was not present in the past. It is present in the ISO's from June 2019 (https://cdimage.debian.org/cdimage/ports/current-hurd-i386/iso-dvd/). Python may want to employ a fallback strategy since whatever is using Python ignores the error and trucks on. Sorry to dump this on you. ----- jwalton at hurd-x86:~$ ls /dev/*rand* /dev/random jwalton at hurd-x86:~$ python --version Python 2.7.16 jwalton at hurd-x86:~$ uname -a GNU hurd-x86 0.9 GNU-Mach 1.8+git20190109-486/Hurd-0.9 i686-AT386 GNU jwalton at hurd-x86:~$ apt-cache show python Package: python Architecture: hurd-i386 Version: 2.7.16-1 Multi-Arch: allowed Priority: standard Section: python Source: python-defaults Maintainer: Matthias Klose Installed-Size: 68 Provides: python-ctypes, python-email, python-importlib, python-profiler, python-wsgiref Pre-Depends: python-minimal (= 2.7.16-1) Depends: python2.7 (>= 2.7.16-1~), libpython-stdlib (= 2.7.16-1), python2 (= 2.7.16-1) ... ---------- components: Interpreter Core messages: 349453 nosy: Jeffrey.Walton priority: normal severity: normal status: open title: _Py_HashRandomization_Init: failed to get random numbers type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 07:05:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 11:05:15 +0000 Subject: [issue37832] _Py_HashRandomization_Init: failed to get random numbers In-Reply-To: <1565607650.45.0.0402326097483.issue37832@roundup.psfhosted.org> Message-ID: <1565607915.86.0.908302116184.issue37832@roundup.psfhosted.org> STINNER Victor added the comment: > It seems HURD no longer provides /dev/urandom out of the box. Why not? How is an application supposed to get entropy from the kernel or from the system? In short, it seems like Python no longer supports HURD anymore. You can patch Python on HURD for your specific needs (ex: put a patch in Debian) if you want to workaround this issue. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 07:23:49 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 11:23:49 +0000 Subject: [issue37804] Remove Thread.isAlive In-Reply-To: <1565364852.41.0.891047152339.issue37804@roundup.psfhosted.org> Message-ID: <1565609029.41.0.224609156272.issue37804@roundup.psfhosted.org> STINNER Victor added the comment: Calling threading.isAlive() starts to emit a DeprecationWarning in Python 3.8. I'm ok to remove the alias in Python 3.9. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 07:23:54 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 11:23:54 +0000 Subject: [issue37804] Remove Thread.isAlive in Python 3.8 In-Reply-To: <1565364852.41.0.891047152339.issue37804@roundup.psfhosted.org> Message-ID: <1565609034.05.0.0135463049276.issue37804@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: Remove Thread.isAlive -> Remove Thread.isAlive in Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 07:23:56 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 11:23:56 +0000 Subject: [issue37804] Remove Thread.isAlive in Python 3.9 In-Reply-To: <1565364852.41.0.891047152339.issue37804@roundup.psfhosted.org> Message-ID: <1565609036.71.0.484255528341.issue37804@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: Remove Thread.isAlive in Python 3.8 -> Remove Thread.isAlive in Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 07:24:45 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 11:24:45 +0000 Subject: [issue37832] Python requires /dev/urandom on HURD: _Py_HashRandomization_Init: failed to get random numbers In-Reply-To: <1565607650.45.0.0402326097483.issue37832@roundup.psfhosted.org> Message-ID: <1565609085.02.0.604110767335.issue37832@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: _Py_HashRandomization_Init: failed to get random numbers -> Python requires /dev/urandom on HURD: _Py_HashRandomization_Init: failed to get random numbers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 07:32:42 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 12 Aug 2019 11:32:42 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565609562.21.0.624533424218.issue37830@roundup.psfhosted.org> Serhiy Storchaka added the comment: Thank you for your report Batuhan. But PR 15221 is not proper way to fix it. It will not work when return an iterable. This issue should be fixed at compiler level. The generated code is: Disassembly of ", line 1>: 2 0 LOAD_GLOBAL 0 (range) 2 LOAD_CONST 1 (2) 4 CALL_FUNCTION 1 6 GET_ITER >> 8 FOR_ITER 24 (to 34) 10 STORE_FAST 0 (number) 3 12 SETUP_FINALLY 12 (to 26) 4 14 LOAD_FAST 0 (number) 16 POP_BLOCK 18 CALL_FINALLY 6 (to 26) 20 ROT_TWO 22 POP_TOP 24 RETURN_VALUE 6 >> 26 POP_FINALLY 0 28 JUMP_ABSOLUTE 8 30 END_FINALLY 32 JUMP_ABSOLUTE 8 >> 34 LOAD_CONST 0 (None) 36 RETURN_VALUE The return statement pushes a value at the stack (offset 14) and the continue statement jumps to the beginning of the loop (offset 28). The stack is not balanced here. ---------- assignee: -> serhiy.storchaka nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 07:32:54 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 12 Aug 2019 11:32:54 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565609574.56.0.266378508663.issue37830@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +lukasz.langa priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 07:34:15 2019 From: report at bugs.python.org (Matthew Bruggeman) Date: Mon, 12 Aug 2019 11:34:15 +0000 Subject: [issue37823] Telnet documentation: fix the link to open() In-Reply-To: <1565540009.68.0.907395311638.issue37823@roundup.psfhosted.org> Message-ID: <1565609655.82.0.276714935548.issue37823@roundup.psfhosted.org> Matthew Bruggeman added the comment: I can take a look ---------- nosy: +Matthew Bruggeman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 07:44:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 11:44:39 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565610279.47.0.491756407967.issue37830@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 07:56:22 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 12 Aug 2019 11:56:22 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565610982.15.0.930862161352.issue37830@roundup.psfhosted.org> Serhiy Storchaka added the comment: It looks to me, that it is not possible to solve this with the current bytecode. Perhaps the only way to fix a crash is to revert issue32489. Implementing Mark's idea about inlining the code of a "finally" block may help to solve the issue with "continue" in "finally". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 07:59:38 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 12 Aug 2019 11:59:38 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565611178.74.0.588507924592.issue37831@roundup.psfhosted.org> Mark Dickinson added the comment: For instances of `int`, `~` does bitwise negation (with the usual two's-complement with an infinite number of bits model that Python uses for all bitwise operations on arbitrary-precision integers). And rightly or wrongly, `True` and `False` are instances of `int`, so it should be possible to use `True` almost anywhere you'd usually use `1`, with no change in behaviour. The proposed change would give us `True == 1` but `~True != ~1`. So I think we're stuck with the current behaviour. Given a time machine, this could arguably be "fixed" by making `True` equal to `-1` rather than `1` ... But absent that time machine, I'd expect some amount of breakage from the proposed change. It's worth noting that NumPy's `bool_` type _does_ do this: >>> import numpy as np >>> ~np.bool_(True) False >>> ~np.bool_(False) True But `np.bool_` doesn't have the same "is-a" relationship with integers: >>> np.bool_.__mro__ (, , ) IOW, -1 from me. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 08:01:26 2019 From: report at bugs.python.org (Batuhan) Date: Mon, 12 Aug 2019 12:01:26 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565611286.83.0.276860421833.issue37830@roundup.psfhosted.org> Batuhan added the comment: Raising an error can handle this because it is impossible to reach to return so we can declare this as an illegal syntax? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 08:02:49 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 12 Aug 2019 12:02:49 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565611369.12.0.229433694804.issue37831@roundup.psfhosted.org> Mark Dickinson added the comment: Looks like this is essentially a duplicate of #12447 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 08:25:51 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 12 Aug 2019 12:25:51 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565612751.78.0.34249003702.issue37830@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 08:35:11 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 12:35:11 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565613311.06.0.305123649191.issue37830@roundup.psfhosted.org> STINNER Victor added the comment: > It looks to me, that it is not possible to solve this with the current bytecode. Perhaps the only way to fix a crash is to revert issue32489. That sounds like a good compromise to unblock next Python 3.8 release. issue32489 can wait another release (Python 3.9), no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 09:00:38 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 13:00:38 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1565614838.14.0.13641450056.issue34155@roundup.psfhosted.org> STINNER Victor added the comment: I change the issue type to security because of https://bugs.python.org/issue34155#msg340534: "Note that this bug was used in an actual security attack so it is serious". ---------- type: behavior -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 09:02:14 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 13:02:14 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1565614934.27.0.301225913544.issue34155@roundup.psfhosted.org> STINNER Victor added the comment: This issue is a security issue so Python 2.7, 3.5, 3.6 should also be fixed, no? ---------- status: closed -> open versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 08:53:59 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 12 Aug 2019 12:53:59 +0000 Subject: [issue37762] IDLE very slow due a super long line output in chunks In-Reply-To: <1565014260.07.0.714424226111.issue37762@roundup.psfhosted.org> Message-ID: <1565614439.87.0.315689601255.issue37762@roundup.psfhosted.org> Tal Einat added the comment: With PR GH-15211 (for issue #37827), which implements terminal-like handling of the \r and \b control characters, the TensorFlow tutorial almost works as intended in the IDLE shell; a minor change to Tensorflow is needed to make it work as intended. Tensorflow inspect sys.stdout to decide whether to use \r and \b control characters is its progress output. Since it recognizes that IDLE's sys.stdout replacement isn't a terminal, it decides not to. Overriding the _dynamic_display attribute of the Progbar class in tensorflow/python/keras/utils/generic_utils.py makes it work very nicely with the above mentioned PR. (I checked this on Windows; it is possible that it will "just work" on other OSs.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 09:07:08 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 13:07:08 +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: <1565615228.76.0.582936145945.issue14465@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 09:13:20 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 13:13:20 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565615600.13.0.664295227024.issue37774@roundup.psfhosted.org> STINNER Victor added the comment: I dislike adding these macros: # define Py_UNLIKELY(value) __builtin_expect(!!(value), 0) # define Py_LIKELY(value) __builtin_expect(!!(value), 1) It's too easy to introduce a performance regression by mistake. IHMO PGO compilation already defeats the purpose of these macros. You should use PGO build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 09:14:06 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 13:14:06 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565615646.33.0.337101916422.issue37774@roundup.psfhosted.org> STINNER Victor added the comment: My previous attempt: bpo-29461. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 09:16:21 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 13:16:21 +0000 Subject: [issue37583] Got a 113 error when running the test_socket In-Reply-To: <1563006871.17.0.626459715079.issue37583@roundup.psfhosted.org> Message-ID: <1565615781.05.0.168204355156.issue37583@roundup.psfhosted.org> STINNER Victor added the comment: I don't understand such error: ====================================================================== ERROR: testSendmsgBadMultiCmsg (test.test_socket.SendmsgTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shihai/workspace/cpython/Lib/test/test_socket.py", line 2649, in setUp self.serv_sock.settimeout(self.fail_timeout) AttributeError: 'SendmsgTests' object has no attribute 'serv_sock' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 09:17:28 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 13:17:28 +0000 Subject: [issue36974] Implement PEP 590 In-Reply-To: <1559154718.16.0.347735090162.issue36974@roundup.psfhosted.org> Message-ID: <1565615848.17.0.606036130926.issue36974@roundup.psfhosted.org> STINNER Victor added the comment: 'SystemError: bad call flags' error message LGTM, I don't think that it should be changed. > Are there many projects that define functions/methods but never call them? I have no idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 09:18:49 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 13:18:49 +0000 Subject: [issue15266] Perform the same checks as PyPI for Description field In-Reply-To: <1341614489.26.0.385769914645.issue15266@psf.upfronthosting.co.za> Message-ID: <1565615929.12.0.679311242649.issue15266@roundup.psfhosted.org> STINNER Victor added the comment: > Why are can I still find these issues in the "Easy issues" list? My bad... I only added a comment but forgot to remove the easy keyword. It's now removed ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 09:19:30 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 13:19:30 +0000 Subject: [issue15266] Perform the same checks as PyPI for Description field In-Reply-To: <1341614489.26.0.385769914645.issue15266@psf.upfronthosting.co.za> Message-ID: <1565615970.44.0.171225721255.issue15266@roundup.psfhosted.org> Change by STINNER Victor : ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 09:22:26 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 13:22:26 +0000 Subject: [issue37415] Error build Python with Intel compiler: doesn't provide atomic_uintptr_t In-Reply-To: <1561563167.55.0.111630694926.issue37415@roundup.psfhosted.org> Message-ID: <1565616146.51.0.433770056656.issue37415@roundup.psfhosted.org> STINNER Victor added the comment: > Changing Include/pyatomic.h to use _Atomic as suggested by Victor in msg346785 leads to the error that _Atomic was undefined. No idea how to define a "_Py_atomic_address" type with icc 2019.4 in this case. If someone has a working patch, I can review it ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 09:29:04 2019 From: report at bugs.python.org (Giovanni Cappellotto) Date: Mon, 12 Aug 2019 13:29:04 +0000 Subject: [issue15266] Perform the same checks as PyPI for Description field In-Reply-To: <1341614489.26.0.385769914645.issue15266@psf.upfronthosting.co.za> Message-ID: <1565616544.4.0.161173637441.issue15266@roundup.psfhosted.org> Change by Giovanni Cappellotto : ---------- nosy: -potomak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 09:59:38 2019 From: report at bugs.python.org (Ricardo Smits) Date: Mon, 12 Aug 2019 13:59:38 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 Message-ID: <1565618378.34.0.81940050082.issue37833@roundup.psfhosted.org> New submission from Ricardo Smits : tkVersion == 8.6 After the new update in macOS (10.14.6): In any python interpreter, when running tk.Tk() it makes macOS crash and logout giving the following error: $ CGSTrackingRegionSetIsEnabled returned CG error 268435459 $ HIToolbox: received notification of WindowServer event port death. ---------- components: macOS messages: 349472 nosy: ned.deily, ronaldoussoren, smits92 priority: normal severity: normal status: open title: tkinter crashes macOS in the latest macOS update 10.14.6 type: crash versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 10:09:34 2019 From: report at bugs.python.org (Dong-hee Na) Date: Mon, 12 Aug 2019 14:09:34 +0000 Subject: [issue37804] Remove Thread.isAlive in Python 3.9 In-Reply-To: <1565364852.41.0.891047152339.issue37804@roundup.psfhosted.org> Message-ID: <1565618974.84.0.27893751778.issue37804@roundup.psfhosted.org> Change by Dong-hee Na : ---------- keywords: +patch pull_requests: +14949 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15225 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 10:25:48 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 12 Aug 2019 14:25:48 +0000 Subject: [issue37642] timezone allows no offset from range (23:59, 24:00) In-Reply-To: <1563709284.19.0.651842013894.issue37642@roundup.psfhosted.org> Message-ID: <1565619948.46.0.833686618095.issue37642@roundup.psfhosted.org> Change by Paul Ganssle : ---------- pull_requests: +14950 pull_request: https://github.com/python/cpython/pull/15226 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 10:30:09 2019 From: report at bugs.python.org (Paul Ganssle) Date: Mon, 12 Aug 2019 14:30:09 +0000 Subject: [issue37642] timezone allows no offset from range (23:59, 24:00) In-Reply-To: <1563709284.19.0.651842013894.issue37642@roundup.psfhosted.org> Message-ID: <1565620209.15.0.404836609114.issue37642@roundup.psfhosted.org> Change by Paul Ganssle : ---------- pull_requests: +14951 pull_request: https://github.com/python/cpython/pull/15227 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 10:48:37 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 12 Aug 2019 14:48:37 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 In-Reply-To: <1565618378.34.0.81940050082.issue37833@roundup.psfhosted.org> Message-ID: <1565621317.39.0.614669337738.issue37833@roundup.psfhosted.org> Ronald Oussoren added the comment: This is almost certainly a bug in macOS. I wonder if it is possible to work around it in Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 11:12:06 2019 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 12 Aug 2019 15:12:06 +0000 Subject: [issue37398] contextlib.ContextDecorator decorating async functions In-Reply-To: <1561445403.56.0.10750759042.issue37398@roundup.psfhosted.org> Message-ID: <1565622726.18.0.856896830258.issue37398@roundup.psfhosted.org> Yury Selivanov added the comment: > I think a simple iscoroutinefunction check will be pretty close to 100% matching what users expect. Yes, "pretty close", but not reliable. :) E.g. I can easily design a decorator that when applied first would break the proposed iscoroutinefunction logic. While decorators like that aren't popular, I'd be wary about introducing a solution that can lead to hours of debugging in some weird (and maybe stupid) cases. > Or, if we don't change the semantics, then we can still be 100% confident that if iscoroutinefunction returns true, then the user has made a mistake. (I.e., if we make this issue a warning, then it's possible we'll miss print a warning in some complicated cases, but we can be confident that all the warnings we do print are correct.) +1 to implement a warning the way you suggest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 11:24:20 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 15:24:20 +0000 Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org> Message-ID: <1565623460.32.0.797962294767.issue37788@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +14952 pull_request: https://github.com/python/cpython/pull/15228 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 11:28:50 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 12 Aug 2019 15:28:50 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565623730.74.0.372546366388.issue37831@roundup.psfhosted.org> Change by Josh Rosenberg : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> ~True is not False _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 11:37:38 2019 From: report at bugs.python.org (Tal Einat) Date: Mon, 12 Aug 2019 15:37:38 +0000 Subject: [issue35855] IDLE squeezer: improve unsqueezing and autosqueeze default In-Reply-To: <1548818070.19.0.784051079348.issue35855@roundup.psfhosted.org> Message-ID: <1565624258.99.0.736844126828.issue35855@roundup.psfhosted.org> Tal Einat added the comment: See issue #37768 regarding opening of help(object) output in a separate window. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 11:40:58 2019 From: report at bugs.python.org (paul j3) Date: Mon, 12 Aug 2019 15:40:58 +0000 Subject: [issue37564] ArgumentParser should support bool type according to truth values In-Reply-To: <1562857832.91.0.995710130518.issue37564@roundup.psfhosted.org> Message-ID: <1565624458.61.0.158589287317.issue37564@roundup.psfhosted.org> paul j3 added the comment: This patch lacks proper documentation, and is too English language specific. For users who assume 'type' means a class rather than function (callable) this change does not need documentation, since it accommodates that assumption. But more experienced users, or ones who read the documentation with care, this change could be puzzling. "Why does 'bool' work?" Admittedly they are unlikely to try it. Still, we are deviating the documented behavior. We also need to pay attention to internationalization. Argparse wraps most error messages and string displays in 'gettext'. There isn't any other part of argparse that assumes that sys.argv strings have English meanings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 11:59:37 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 12 Aug 2019 15:59:37 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565625577.55.0.825866064001.issue37831@roundup.psfhosted.org> Raymond Hettinger added the comment: +0 This proposal may be worth re-considering. I've seen the problem arise in practice on multiple occasions. I suspect that it will continue to give people trouble. Right now, a bool is-a int that 1) only has two singleton instances equal to zero and one, 2) has a different repr, and 3) has the & | and ^ operations redefined to return instances of bool. I think we could also override the ~ operation. That would be a Liskov violation, making bools slightly less substitutable for ints, but it does so in a way that is intuitive and likely to match what a user intends when inverting a bool. ---------- nosy: +rhettinger, tim.peters status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 12:11:07 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 12 Aug 2019 16:11:07 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565626267.25.0.783037739351.issue37831@roundup.psfhosted.org> Mark Dickinson added the comment: See also the discussion started by Antoine here: https://mail.python.org/pipermail//python-ideas/2016-April/039488.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 12:11:18 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 12 Aug 2019 16:11:18 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565626278.61.0.712730256683.issue37831@roundup.psfhosted.org> Change by Mark Dickinson : ---------- stage: resolved -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 12:11:39 2019 From: report at bugs.python.org (Sascha Silbe) Date: Mon, 12 Aug 2019 16:11:39 +0000 Subject: [issue23837] asyncio: read pipe transport tries to resume reading after loop is gone In-Reply-To: <1427882762.68.0.794378524046.issue23837@psf.upfronthosting.co.za> Message-ID: <1565626299.97.0.615590179512.issue23837@roundup.psfhosted.org> Change by Sascha Silbe : ---------- nosy: +sascha_silbe _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 12:33:22 2019 From: report at bugs.python.org (hai shi) Date: Mon, 12 Aug 2019 16:33:22 +0000 Subject: [issue37583] Got a 113 error when running the test_socket In-Reply-To: <1563006871.17.0.626459715079.issue37583@roundup.psfhosted.org> Message-ID: <1565627602.77.0.720643925091.issue37583@roundup.psfhosted.org> hai shi added the comment: Oh, sorry, victor. I use ./python -m unittest xxx before. Updating the test result again. ---------- Added file: https://bugs.python.org/file48538/test_socket_fail_info_v2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 12:57:20 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Aug 2019 16:57:20 +0000 Subject: [issue32912] Raise non-silent warning for invalid escape sequences In-Reply-To: <1519324497.82.0.467229070634.issue32912@psf.upfronthosting.co.za> Message-ID: <1565629040.1.0.478858963034.issue32912@roundup.psfhosted.org> Change by Steve Dower : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 13:08:59 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 12 Aug 2019 17:08:59 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565629739.52.0.839312043433.issue37831@roundup.psfhosted.org> Serhiy Storchaka added the comment: -1 from me too. Making True == -1 looks interesting, but it has drawbacks. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 13:41:31 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 17:41:31 +0000 Subject: [issue37804] Remove Thread.isAlive in Python 3.9 In-Reply-To: <1565364852.41.0.891047152339.issue37804@roundup.psfhosted.org> Message-ID: <1565631691.55.0.102245704801.issue37804@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 44046fe4fc7f00a6eb855b33e6a3f953cf5233a5 by Victor Stinner (Dong-hee Na) in branch 'master': bpo-37804: Remove the deprecated method threading.Thread.isAlive() (GH-15225) https://github.com/python/cpython/commit/44046fe4fc7f00a6eb855b33e6a3f953cf5233a5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 13:42:00 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 12 Aug 2019 17:42:00 +0000 Subject: [issue37804] Remove Thread.isAlive in Python 3.9 In-Reply-To: <1565364852.41.0.891047152339.issue37804@roundup.psfhosted.org> Message-ID: <1565631720.77.0.471120008217.issue37804@roundup.psfhosted.org> Change by STINNER Victor : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 14:18:36 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 12 Aug 2019 18:18:36 +0000 Subject: [issue32489] Allow 'continue' in 'finally' clause In-Reply-To: <1515013867.94.0.467229070634.issue32489@psf.upfronthosting.co.za> Message-ID: <1565633916.67.0.758059297009.issue32489@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +14954 pull_request: https://github.com/python/cpython/pull/15230 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 14:18:36 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 12 Aug 2019 18:18:36 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565633916.52.0.00626887132382.issue37830@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +14953 pull_request: https://github.com/python/cpython/pull/15230 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 14:24:34 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 12 Aug 2019 18:24:34 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565634274.63.0.926632949281.issue37831@roundup.psfhosted.org> Mark Dickinson added the comment: > Making True == -1 looks interesting, but it has drawbacks. Yes, please ignore that part of my post. :-) It shouldn't be considered seriously until a time machine turns up (and probably not even then). My main worry with the proposed change is accidental breakage from the change in meaning. I've so far failed to find any examples of real-world functions that could/would be broken - the closest I've come is floating-point bit-pattern manipulation functions (constructing a bit-string from a sign, exponent and significand, where it's quite natural to treat the sign both as an "is_negative" boolean and as a 0-or-1 integer). But that case didn't involve a `~sign` at any point, so it doesn't count. Still, I have a nagging suspicion that such a function will turn up if we make this change. Having ~True *not* be the same as ~1 feels like a bigger surprise to me than having ~True not be False; it breaks my simple mental model that bools always behave like ints in numeric contexts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 14:26:40 2019 From: report at bugs.python.org (Batuhan) Date: Mon, 12 Aug 2019 18:26:40 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565633916.54.0.350984140363.issue37830@roundup.psfhosted.org> Message-ID: Batuhan added the comment: I closed the my PR in favor of Serhiy's PR. On Mon, Aug 12, 2019, 9:18 PM Serhiy Storchaka wrote: > > Change by Serhiy Storchaka : > > > ---------- > pull_requests: +14953 > pull_request: https://github.com/python/cpython/pull/15230 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 14:28:32 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 12 Aug 2019 18:28:32 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565634512.31.0.637618794644.issue37831@roundup.psfhosted.org> Mark Dickinson added the comment: There's also the minor annoyance that there isn't currently an obvious safe way to convert an integer-like thing to an actual int, to make sure that bools do the right thing in a numeric context. operator.index *ought* to be that obvious way, but it leaves bools untouched. >>> operator.index(True) True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 14:39:22 2019 From: report at bugs.python.org (Ned Deily) Date: Mon, 12 Aug 2019 18:39:22 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 In-Reply-To: <1565618378.34.0.81940050082.issue37833@roundup.psfhosted.org> Message-ID: <1565635162.82.0.305397504845.issue37833@roundup.psfhosted.org> Ned Deily added the comment: Can you be more specific about the source of your Pythons and Tk 8.6 and exactly what version it is? Tk through tkinter seems to work as expected (and without a crash) when I try the current Python.org pythons with their built-in Tk 8.6.6 or current MscPorts Pythons with their Tk 8.6.9 all running on the latest released 10.14.6 with Supplemental Update on a MacBook Pro. Ronald, are you able to reproduce this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 14:49:22 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Aug 2019 18:49:22 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links Message-ID: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> New submission from Steve Dower : The IO_REPARSE_TAG_APPEXECLINK was introduced for aliases to installed UWP apps that require activation before they can be executed. Currently these are in an unusual place as far as Python support goes - stat() fails where lstat() succeeds, but the lstat() result doesn't have the right flags to make is_link() return True. It's not clear whether we *should* treat these as regular symlinks, given there are a number of practical differences, but since we can enable it I'm going to post a PR anyway. ---------- components: Windows messages: 349486 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: readlink on Windows cannot read app exec links versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 15:01:06 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Aug 2019 19:01:06 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565636466.05.0.137642769288.issue37834@roundup.psfhosted.org> Change by Steve Dower : ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 15:01:49 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Aug 2019 19:01:49 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565636509.39.0.025515186481.issue37834@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch pull_requests: +14955 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15231 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 15:03:04 2019 From: report at bugs.python.org (Tim Peters) Date: Mon, 12 Aug 2019 19:03:04 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565636584.86.0.365373923889.issue37831@roundup.psfhosted.org> Tim Peters added the comment: Mark, isn't `int()` the obvious way "to convert an integer-like thing to an actual int"? >>> int(True) 1 >>> int(False) 0 For the rest, I'm -True on making ~ do something magical for bools inconsistent with what it does for ints. "is-a" is a promise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 15:11:04 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 12 Aug 2019 19:11:04 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565637064.55.0.886377293681.issue37831@roundup.psfhosted.org> Serhiy Storchaka added the comment: For reference, the link to the Python-Ideas discussion in Mailman 3: https://mail.python.org/archives/list/python-ideas at python.org/thread/7UR3XGXNLGCM6QFR7KTIQ2QGVRS6QNZH/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 15:22:07 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 12 Aug 2019 19:22:07 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565637727.78.0.176536493304.issue37831@roundup.psfhosted.org> Mark Dickinson added the comment: > isn't `int()` the obvious way "to convert an integer-like thing to an actual int"? Well sorta, except that it's too lenient, letting in strings, floats, Decimal instances and the like. The strings isn't so much of an issue - it's more the silent truncation with the floats and Decimals that's problematic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 15:34:42 2019 From: report at bugs.python.org (Roundup Robot) Date: Mon, 12 Aug 2019 19:34:42 +0000 Subject: [issue16637] py-bt, py-locals, etc. GDB commands fail with output-radix 16 In-Reply-To: <1354903492.9.0.822155625877.issue16637@psf.upfronthosting.co.za> Message-ID: <1565638482.95.0.51712262173.issue16637@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +14956 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15232 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 15:56:50 2019 From: report at bugs.python.org (Ricardo Smits) Date: Mon, 12 Aug 2019 19:56:50 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 In-Reply-To: <1565635162.82.0.305397504845.issue37833@roundup.psfhosted.org> Message-ID: Ricardo Smits added the comment: I am on a Conda environment with Python 3.7.4 with the corresponding Tkinter 8.6 that came with it. I tried to use some apps I compiled with Pyinstaller and all of them caused this crash. So I tried line by line on the terminal (to cross out Pyinstaller as the problem) and "root = tk.Tk()" was where it crashed for me. Here are more people with the same issues: https://github.com/pyinstaller/pyinstaller/issues/4334 As Ronald said, most certainly it is a macOS bug, but I don't think they will bother to fix this when they are so close to their 10.15 release :/ On Mon, Aug 12, 2019 at 8:39 PM Ned Deily wrote: > > Ned Deily added the comment: > > Can you be more specific about the source of your Pythons and Tk 8.6 and > exactly what version it is? Tk through tkinter seems to work as expected > (and without a crash) when I try the current Python.org pythons with their > built-in Tk 8.6.6 or current MscPorts Pythons with their Tk 8.6.9 all > running on the latest released 10.14.6 with Supplemental Update on a > MacBook Pro. > > Ronald, are you able to reproduce this? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 16:06:06 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Aug 2019 20:06:06 +0000 Subject: [issue37354] Write PowerShell Activate.ps1 to be static so it can be signed In-Reply-To: <1561055369.2.0.393754678677.issue37354@roundup.psfhosted.org> Message-ID: <1565640366.53.0.735635247131.issue37354@roundup.psfhosted.org> Steve Dower added the comment: New changeset 732775d6be8062e72cf4995d5a9db0170e22c233 by Steve Dower (Derek Keeler) in branch 'master': bpo-37354: Make Powershell Activate.ps1 script static to allow for signing (GH-14967) https://github.com/python/cpython/commit/732775d6be8062e72cf4995d5a9db0170e22c233 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 16:06:22 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 12 Aug 2019 20:06:22 +0000 Subject: [issue37354] Write PowerShell Activate.ps1 to be static so it can be signed In-Reply-To: <1561055369.2.0.393754678677.issue37354@roundup.psfhosted.org> Message-ID: <1565640382.35.0.7433363031.issue37354@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14957 pull_request: https://github.com/python/cpython/pull/15233 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 16:09:01 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Aug 2019 20:09:01 +0000 Subject: [issue37354] Write PowerShell Activate.ps1 to be static so it can be signed In-Reply-To: <1561055369.2.0.393754678677.issue37354@roundup.psfhosted.org> Message-ID: <1565640541.7.0.334340843029.issue37354@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +14958 pull_request: https://github.com/python/cpython/pull/15235 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 16:23:03 2019 From: report at bugs.python.org (Ned Deily) Date: Mon, 12 Aug 2019 20:23:03 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 In-Reply-To: <1565618378.34.0.81940050082.issue37833@roundup.psfhosted.org> Message-ID: <1565641383.61.0.729650532946.issue37833@roundup.psfhosted.org> Ned Deily added the comment: Thanks for the link but that really doesn?t pin down exactly what Tk is in use. This probably should be pursued with the Tk project. Adding Kevin Walzer from Tk: Kevin, does this problem sound familiar? ---------- nosy: +wordtech _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 16:25:46 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 12 Aug 2019 20:25:46 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565641546.27.0.364714952617.issue37831@roundup.psfhosted.org> Raymond Hettinger added the comment: Okay, we'll just continue to tell users "you're holding it wrong" ;-) ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 16:32:35 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 12 Aug 2019 20:32:35 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565641955.21.0.857346954733.issue37831@roundup.psfhosted.org> Raymond Hettinger added the comment: It may have been a mistake to directly support | & and ^. That implies ~ should work. The fallback is to use "not" but that looks weird and has the wrong operator precedence: (not a) ^ (not b & c) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 16:53:45 2019 From: report at bugs.python.org (Tim Peters) Date: Mon, 12 Aug 2019 20:53:45 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565643225.11.0.361531125523.issue37831@roundup.psfhosted.org> Tim Peters added the comment: I don't agree that "~" doesn't "work". If people are reading it as "not", they're in error. The Python docs say ~x means the bits of x inverted and that's what it does. There's no sense it which it was _intended_ to be logical negation, no more in Python than in C (C has the distinct unary prefix "!" operator for truthiness negation, and, as you note, Python has "not"). It's educational ;-) to learn how analogies between ints and bools can break down. For logical negation in the sense they want here, it's not "~x" they want but "~x & 1" - that is, if someone insists on using an inappropriate operator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 17:09:31 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Aug 2019 21:09:31 +0000 Subject: [issue37354] Write PowerShell Activate.ps1 to be static so it can be signed In-Reply-To: <1561055369.2.0.393754678677.issue37354@roundup.psfhosted.org> Message-ID: <1565644171.76.0.742849430685.issue37354@roundup.psfhosted.org> Steve Dower added the comment: New changeset 0c64b57e0155c333b7c96ec2af009c1388cd5d31 by Steve Dower (Miss Islington (bot)) in branch '3.8': [3.8] bpo-37354: Make Powershell Activate.ps1 script static to allow for signing (GH-14967) https://github.com/python/cpython/commit/0c64b57e0155c333b7c96ec2af009c1388cd5d31 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 17:09:39 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Aug 2019 21:09:39 +0000 Subject: [issue37354] Write PowerShell Activate.ps1 to be static so it can be signed In-Reply-To: <1561055369.2.0.393754678677.issue37354@roundup.psfhosted.org> Message-ID: <1565644179.62.0.327878048133.issue37354@roundup.psfhosted.org> Steve Dower added the comment: New changeset 3e34a25a7a5c9ea2c46f2daeeb60f072faa5aaa1 by Steve Dower in branch 'master': bpo-37354: Sign Activate.ps1 for release (GH-15235) https://github.com/python/cpython/commit/3e34a25a7a5c9ea2c46f2daeeb60f072faa5aaa1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 17:09:49 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 12 Aug 2019 21:09:49 +0000 Subject: [issue37354] Write PowerShell Activate.ps1 to be static so it can be signed In-Reply-To: <1561055369.2.0.393754678677.issue37354@roundup.psfhosted.org> Message-ID: <1565644189.73.0.350283475289.issue37354@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14959 pull_request: https://github.com/python/cpython/pull/15236 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 17:19:39 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Aug 2019 21:19:39 +0000 Subject: [issue37354] Write PowerShell Activate.ps1 to be static so it can be signed In-Reply-To: <1561055369.2.0.393754678677.issue37354@roundup.psfhosted.org> Message-ID: <1565644779.47.0.177292183109.issue37354@roundup.psfhosted.org> Steve Dower added the comment: Thanks, Derek! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 17:20:15 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Aug 2019 21:20:15 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565644815.7.0.721844187094.issue37834@roundup.psfhosted.org> Steve Dower added the comment: Added an update with a new stat field (st_reparse_tag) so that we can tell them apart, which also means I can add a test for readlink. ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 17:35:22 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 12 Aug 2019 21:35:22 +0000 Subject: [issue37354] Write PowerShell Activate.ps1 to be static so it can be signed In-Reply-To: <1561055369.2.0.393754678677.issue37354@roundup.psfhosted.org> Message-ID: <1565645722.01.0.0304501655111.issue37354@roundup.psfhosted.org> miss-islington added the comment: New changeset 2b98d8ec7ec3d41c6403ff9f6677a00ea0cb8b92 by Miss Islington (bot) in branch '3.8': bpo-37354: Sign Activate.ps1 for release (GH-15235) https://github.com/python/cpython/commit/2b98d8ec7ec3d41c6403ff9f6677a00ea0cb8b92 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 18:32:24 2019 From: report at bugs.python.org (Eryk Sun) Date: Mon, 12 Aug 2019 22:32:24 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565649144.03.0.773707085075.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: Symlinks are specially interpreted by the file API, I/O manager, and network redirector. So I think they should remain a separate category. readlink() and is_link() should be reserved for POSIX symlinks, i.e. only IO_REPARSE_TAG_SYMLINK. These app-exec reparse points are not name surrogates (i.e. 0x2000_0000 set in the tag), and they lack an associated filter driver that handles them in normal file operations. I/O syscalls that try to reparse the path fail with STATUS_IO_REPARSE_TAG_NOT_HANDLED. It's also messy to conflate different things in general for the sake of a particular case. For example, if code sees the app-exec link as a symlink because ntpath.is_link() is true, it may try to copy it via os.readlink() and os.symlink(). This creates a different type of reparse point, if the user even has the symlink privilege, which may not behave the same as the original app-exec link in a CreateProcessW call. (I don't know what the end goal is for the Windows team in terms of allowing app executables under "%ProgramFiles%\WindowsApps" to be executed directly.) How about adding a separate function such as nt.read_reparse_point() that's able to read reparse points that are documented (most types are opaque) and can be interpreted as a string, or a tuple of strings? The internal implementation could be shared with os.readlink. The current behavior of follow_symlinks in stat() is problematic. It should be limited to symlinks. So another idea that I think could prove generally useful is to extend stat() and lstat() with a follow_reparse_points=True parameter. If false, it would imply follow_symlinks is false. Explicitly passing follow_symlinks=True with follow_reparse_points=False would be an error. With follow_symlinks=False and follow_reparse_points=True, it would only open a symlink and follow all other types of reparse points. The stat result would gain an st_reparse_tag field (already added by your PR), which would be non-zero whenever a reparse point is opened. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 18:47:52 2019 From: report at bugs.python.org (Eryk Sun) Date: Mon, 12 Aug 2019 22:47:52 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565650072.62.0.0941014718801.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > How about adding a separate function such as nt.read_reparse_point() If we support reading junctions, this should be using the substitute name (with \??\ replaced by \\?\) instead of the print name. For both symlinks and junctions, [MS-FSCC] 2.1.2 states that the print name SHOULD be informative, not that it MUST be, where SHOULD and MUST are defined by RFC2119. The print name can be non-informative for some reason (e.g. maybe to use the whole 16 KiB buffer for the target path.) For symlinks that's not normally observed, since CreateSymbolicLinkW is conservative. For junctions, applications and frameworks use a low-level IOCTL to set them, and they're not necessarily bothering to set a print name. For example, PowerShell omits it: PS C:\Mount> new-item Spam -type junction -value C:\Temp\Spam | out-null PS C:\Mount> fsutil.exe reparsepoint query spam Reparse Tag Value : 0xa0000003 Tag value: Microsoft Tag value: Name Surrogate Tag value: Mount Point Substitue Name offset: 0 Substitue Name length: 32 Print Name offset: 34 Print Name Length: 0 Substitute Name: \??\C:\Temp\Spam This mount point works fine despite the lack of a print name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 18:55:23 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 12 Aug 2019 22:55:23 +0000 Subject: [issue37759] Polish whatsnew for 3.8 In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org> Message-ID: <1565650523.27.0.563160097314.issue37759@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 66a34d35e4c97da9840a29ba9fba76721021c463 by Raymond Hettinger in branch 'master': bpo-37759: Second round of edits to Whatsnew 3.8 (GH-15204) https://github.com/python/cpython/commit/66a34d35e4c97da9840a29ba9fba76721021c463 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 18:57:36 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 12 Aug 2019 22:57:36 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565650656.96.0.475613012369.issue37834@roundup.psfhosted.org> Steve Dower added the comment: Thanks Eryk for your valuable response :) > readlink() and is_link() should be reserved for POSIX symlinks, i.e. only IO_REPARSE_TAG_SYMLINK. I'm okay with that reasoning. Honestly, the only real problem I've seen is in applications that use a reimplementation of spawn() rather than the UCRT's version (which handles the reparse point jsut fine). > they lack an associated filter driver that handles them in normal file operations Also true, and likely to be a cause of more problems. But not ours to fix :) > How about adding a separate function such as nt.read_reparse_point() that's able to read reparse points [...]? The internal implementation could be shared with os.readlink. Maybe it can just return bytes and let the caller do the parsing? > The current behavior of follow_symlinks in stat() is problematic. It should be limited to symlinks. This sounds like a good option to me, too. So that would suggest that Modules/posixmodule.c in win32_xstat_impl would verify both FILE_ATTRIBUTE_REPARSE_POINT and IO_REPARSE_TAG_SYMLINK? And if the tag is different it'll return information about the reparse point rather than the target? > The stat result would gain an st_reparse_tag field (already added by your PR), which would be non-zero whenever a reparse point is opened. I agree this can stay. We don't need the rest of the logic here - callers who care to follow non-symlink reparse points can use the new nt.read_reparse_point() function to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 19:04:05 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Mon, 12 Aug 2019 23:04:05 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565651045.79.0.858367092273.issue37764@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- keywords: +patch pull_requests: +14960 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15239 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 19:09:39 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Mon, 12 Aug 2019 23:09:39 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565651379.61.0.982482113101.issue37764@roundup.psfhosted.org> Ashwin Ramaswami added the comment: Oh, both the Travis links I sent actually ended up reproducing the bug. I've made a PR that fixes with an even smaller test case: get_unstructured('=?utf-8?q?somevalue?=aa') It looks like this is caused because "aa" is thought to be an encoded word escape in https://github.com/python/cpython/blob/fd5a82a7685d1599aab12e722a383cb0a2adfd8a/Lib/email/_header_value_parser.py#L1042 -- thus, get_encoded_word fails, which ends up making get_unstructured go in an infinite loop. My PR makes the parser parse "=?utf-8?q?somevalue?=aa" as "=?utf-8?q?somevalue?=aa". However, the existing test cases make sure it parses "=?utf-8?q?somevalue?=nowhitespace" as "somevaluenowhitespace". I'm not too familiar with RFC 2047, but why are "aa" and "nowhitespace" treated differently? Should they be? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 19:18:09 2019 From: report at bugs.python.org (Charles) Date: Mon, 12 Aug 2019 23:18:09 +0000 Subject: [issue34916] Add create_window_function() to sqlite3.Connection In-Reply-To: <1538846966.09.0.545547206417.issue34916@psf.upfronthosting.co.za> Message-ID: <1565651889.9.0.573864909609.issue34916@roundup.psfhosted.org> Charles added the comment: I've implemented this in a fork / standalone packaging of the Python 3.x sqlite3 module. You can find the relevant portions (and a couple unrelated changes) in this commit: https://github.com/coleifer/pysqlite3/commit/91c20016fd3fd3d1d7ade475893046958f7faa00 ---------- nosy: +coleifer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 19:23:06 2019 From: report at bugs.python.org (Charles) Date: Mon, 12 Aug 2019 23:23:06 +0000 Subject: [issue16958] The sqlite3 context manager does not work with isolation_level=None In-Reply-To: <1358124405.04.0.0310758361359.issue16958@psf.upfronthosting.co.za> Message-ID: <1565652186.2.0.539546332411.issue16958@roundup.psfhosted.org> Charles added the comment: > With isolation_level set to None, the sqlite3 library is in autocommit mode, so changes will get committed immediately inside the with, which is simply broken. Not necessarily. When sqlite is in autocommit mode, you can still open transactions by executing a BEGIN query. In fact, that's the main reason to use isolation_level=None -- you can manage the transactions yourself. ---------- nosy: +coleifer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 20:00:13 2019 From: report at bugs.python.org (Tim Peters) Date: Tue, 13 Aug 2019 00:00:13 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565654413.1.0.644339982948.issue37831@roundup.psfhosted.org> Tim Peters added the comment: BTW, I should clarify that I think the real "sin" here was making bool a subclass of int to begin with. For example, there's no sane reason at all for bools to support division, and no reason for a distinct type not to define "~" any way it feels like. Advertised inheritance is usually a Bad Idea ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 20:14:46 2019 From: report at bugs.python.org (Eryk Sun) Date: Tue, 13 Aug 2019 00:14:46 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565655286.69.0.490010948172.issue37831@roundup.psfhosted.org> Eryk Sun added the comment: We could extend bool with shades of grey that close the 2-bit, signed set over the complement: {-2, -1, 0, 1}. For example, the bitwise complement of False could be RealNews (-1, 0x11) and the bitwise complement of True could be FakeNews (-2, 0x10). The bool() value some of built-in objects could be declared as RealNews or FakeNews by decree of the steering committee. For other projects this would have to be subject to opinion, which will probably lead to endless internal debates and flame wars. In a boolean context, FakeNews would be falsey and RealNews would be truthy. For bitwise operations, we have the following: ~False -> RealNews ~True -> FakeNews False & FakeNews -> False False & RealNews -> False True & FakeNews -> False True & RealNews -> True RealNews & FakeNews -> FakeNews False | FakeNews -> FakeNews False | RealNews -> RealNews True | FakeNews -> RealNews True | RealNews -> RealNews RealNews | FakeNews -> RealNews False ^ FakeNews -> FakeNews False ^ RealNews -> RealNews True ^ FakeNews -> RealNews True ^ RealNews -> FakeNews RealNews ^ FakeNews -> True ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 20:52:34 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 13 Aug 2019 00:52:34 +0000 Subject: [issue37759] Polish whatsnew for 3.8 In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org> Message-ID: <1565657554.48.0.910970557791.issue37759@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +14961 pull_request: https://github.com/python/cpython/pull/15240 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 20:55:47 2019 From: report at bugs.python.org (Abhilash Raj) Date: Tue, 13 Aug 2019 00:55:47 +0000 Subject: [issue37826] Document PEP 3134 in tutorials/errors.rst In-Reply-To: <1565548566.46.0.213467869715.issue37826@roundup.psfhosted.org> Message-ID: <1565657747.14.0.0238790244655.issue37826@roundup.psfhosted.org> Abhilash Raj added the comment: Yes, I am gonna work on a PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 21:00:26 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 13 Aug 2019 01:00:26 +0000 Subject: [issue37759] Polish whatsnew for 3.8 In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org> Message-ID: <1565658026.9.0.374546121355.issue37759@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +14962 pull_request: https://github.com/python/cpython/pull/15241 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 21:03:01 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 13 Aug 2019 01:03:01 +0000 Subject: [issue37759] Polish whatsnew for 3.8 In-Reply-To: <1564971591.59.0.825854790144.issue37759@roundup.psfhosted.org> Message-ID: <1565658181.21.0.37503002983.issue37759@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 9bedb8c9e60fab4f49ee12b95f8073ee9f577f81 by Raymond Hettinger in branch '3.8': bpo-37759: Second round of edits to Whatsnew 3.8 (GH-15204) (GH-15240) https://github.com/python/cpython/commit/9bedb8c9e60fab4f49ee12b95f8073ee9f577f81 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 21:10:28 2019 From: report at bugs.python.org (Zackery Spytz) Date: Tue, 13 Aug 2019 01:10:28 +0000 Subject: [issue15010] unittest: _top_level_dir is incorrectly persisted between calls to different load_test methods In-Reply-To: <1338945643.44.0.808523506511.issue15010@psf.upfronthosting.co.za> Message-ID: <1565658628.14.0.0359573474967.issue15010@roundup.psfhosted.org> Change by Zackery Spytz : ---------- pull_requests: +14963 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15242 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 21:12:14 2019 From: report at bugs.python.org (Zackery Spytz) Date: Tue, 13 Aug 2019 01:12:14 +0000 Subject: [issue15010] unittest: _top_level_dir is incorrectly persisted between calls to different load_test methods In-Reply-To: <1338945643.44.0.808523506511.issue15010@psf.upfronthosting.co.za> Message-ID: <1565658734.19.0.354201894299.issue15010@roundup.psfhosted.org> Change by Zackery Spytz : ---------- nosy: +ZackerySpytz versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 21:13:05 2019 From: report at bugs.python.org (Zackery Spytz) Date: Tue, 13 Aug 2019 01:13:05 +0000 Subject: [issue22811] _top_level_dir state leaks on defaultTestLoader In-Reply-To: <1415340312.36.0.0686984074156.issue22811@psf.upfronthosting.co.za> Message-ID: <1565658785.86.0.617446872528.issue22811@roundup.psfhosted.org> Zackery Spytz added the comment: It seems that this issue is a duplicate of bpo-15010. ---------- nosy: +ZackerySpytz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 21:22:41 2019 From: report at bugs.python.org (ppperry) Date: Tue, 13 Aug 2019 01:22:41 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565659361.2.0.80597839173.issue37830@roundup.psfhosted.org> ppperry added the comment: Unfortunately, there's a similar bug for `break` in a finally inside two nested loops, so just re-banning `continue` won't fix the crash. The code below segfaults: ``` def simple(): for number in range(2): for number in range(2): try: return number finally: break simple() ``` ---------- nosy: +ppperry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 21:27:28 2019 From: report at bugs.python.org (Abhilash Raj) Date: Tue, 13 Aug 2019 01:27:28 +0000 Subject: [issue37826] Document PEP 3134 in tutorials/errors.rst In-Reply-To: <1565548566.46.0.213467869715.issue37826@roundup.psfhosted.org> Message-ID: <1565659648.21.0.45376975244.issue37826@roundup.psfhosted.org> Change by Abhilash Raj : ---------- keywords: +patch pull_requests: +14964 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15243 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 22:21:29 2019 From: report at bugs.python.org (alvis) Date: Tue, 13 Aug 2019 02:21:29 +0000 Subject: [issue37677] Seg Fault on OSX when multiprocessing In-Reply-To: <1564042021.53.0.0155934240157.issue37677@roundup.psfhosted.org> Message-ID: <1565662889.77.0.279611388892.issue37677@roundup.psfhosted.org> alvis added the comment: Hi, sorry i am unable to provide a standalone script that cause this issue, as it happen once every few weeks. Is it similar to the no_proxy=* issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 12 23:52:12 2019 From: report at bugs.python.org (Gregory Szorc) Date: Tue, 13 Aug 2019 03:52:12 +0000 Subject: [issue31601] Availability of utimensat, futimens not checked correctly on macOS In-Reply-To: <1506493420.2.0.154975027568.issue31601@psf.upfronthosting.co.za> Message-ID: <1565668332.78.0.792893474176.issue31601@roundup.psfhosted.org> Gregory Szorc added the comment: I ran into this with PyOxidizer. CPython's `configure` needs to be made aware of the current macOS SDK version and filter out symbols not present in the target macOS version. I worked around it by `undef`'ing some entries from the generated `pyconfig.h` file. macOS's clang does emit some warnings when it sees symbols that shouldn't be used with the current target version. CPython's build system should consider adding -Werror=unguarded-availability-new to CFLAGS to turn these warnings into errors so they are caught at compile time and not run time. But there should be proper filtering of affected symbols first, otherwise people won't be able to build CPython when targeting older macOS versions. ---------- nosy: +indygreg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 00:02:58 2019 From: report at bugs.python.org (Kevin Walzer) Date: Tue, 13 Aug 2019 04:02:58 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 In-Reply-To: <1565618378.34.0.81940050082.issue37833@roundup.psfhosted.org> Message-ID: <1565668978.29.0.236807430811.issue37833@roundup.psfhosted.org> Kevin Walzer added the comment: Hard to say what is going on without knowing more about the specific version of Tk (not just 8.6, but 8.6.8? 8.6.9?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 00:43:31 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Tue, 13 Aug 2019 04:43:31 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1565671411.46.0.963466740691.issue21109@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- pull_requests: +14965 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/15244 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 00:47:17 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Tue, 13 Aug 2019 04:47:17 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1565671637.97.0.491329696998.issue21109@roundup.psfhosted.org> Ashwin Ramaswami added the comment: I've added a PR in which I'm working on adding in the tests. Wanted to make sure this is the approach you had in mind? It wasn't as simple as how tests are handled in, say, test_binascii.py, because over there there was only one class that handled the main test suite, while in this file, there are multiple. ---------- nosy: +epicfaace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 01:10:33 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 13 Aug 2019 05:10:33 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565673033.92.0.326238367634.issue37760@roundup.psfhosted.org> Benjamin Peterson added the comment: Thanks for working this. In your interested in doing some more hacking on Unicode data, there's #32771. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 01:21:06 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 13 Aug 2019 05:21:06 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565673666.89.0.888766421969.issue37760@roundup.psfhosted.org> Benjamin Peterson added the comment: New changeset ef2af1ad44be0542a47270d5173a0b920c3a450d by Benjamin Peterson (Greg Price) in branch 'master': bpo-37760: Factor out the basic UCD parsing logic of makeunicodedata. (GH-15130) https://github.com/python/cpython/commit/ef2af1ad44be0542a47270d5173a0b920c3a450d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 01:23:45 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 05:23:45 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565673825.53.0.233375351744.issue37760@roundup.psfhosted.org> miss-islington added the comment: New changeset 4e3dfcc4b987e683476a1b16456e57d3c9f581cb by Miss Islington (bot) (Greg Price) in branch 'master': bpo-37760: Mark all generated Unicode data headers as generated. (GH-15171) https://github.com/python/cpython/commit/4e3dfcc4b987e683476a1b16456e57d3c9f581cb ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 01:23:51 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 05:23:51 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565673831.8.0.690489237538.issue37760@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14966 pull_request: https://github.com/python/cpython/pull/15245 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 01:30:22 2019 From: report at bugs.python.org (Dong-hee Na) Date: Tue, 13 Aug 2019 05:30:22 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1565674222.44.0.130509994734.issue37798@roundup.psfhosted.org> Dong-hee Na added the comment: @rhettinger Hi, Can I work on this issue? It might be my first C module addition task for CPython. ---------- nosy: +corona10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 01:48:10 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 05:48:10 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565675290.8.0.162600246277.issue37760@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14967 pull_request: https://github.com/python/cpython/pull/15246 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 01:52:47 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Aug 2019 05:52:47 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565675567.27.0.58840665598.issue37831@roundup.psfhosted.org> Serhiy Storchaka added the comment: :-D ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 01:58:04 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 13 Aug 2019 05:58:04 +0000 Subject: [issue37758] unicodedata checksum-tests only test 1/17th of Unicode's codepoints In-Reply-To: <1564967162.48.0.525882022653.issue37758@roundup.psfhosted.org> Message-ID: <1565675884.21.0.544360365026.issue37758@roundup.psfhosted.org> Benjamin Peterson added the comment: New changeset def97c988be8340f33869b57942a30d10fc3a1f9 by Benjamin Peterson (Greg Price) in branch 'master': bpo-37758: Clean out vestigial script-bits from test_unicodedata. (GH-15126) https://github.com/python/cpython/commit/def97c988be8340f33869b57942a30d10fc3a1f9 ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 01:59:33 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 13 Aug 2019 05:59:33 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565675973.7.0.933008117055.issue37760@roundup.psfhosted.org> Benjamin Peterson added the comment: New changeset 99d208efed97e02d813e8166925b998bbd0d3993 by Benjamin Peterson (Greg Price) in branch 'master': bpo-37760: Constant-fold some old options in makeunicodedata. (GH-15129) https://github.com/python/cpython/commit/99d208efed97e02d813e8166925b998bbd0d3993 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 02:04:24 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 06:04:24 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565676264.48.0.827064395734.issue37760@roundup.psfhosted.org> miss-islington added the comment: New changeset c2b9d9f202e4a99fc0800b7a0f0944ac4c2382e3 by Miss Islington (bot) in branch '3.8': bpo-37760: Mark all generated Unicode data headers as generated. (GH-15171) https://github.com/python/cpython/commit/c2b9d9f202e4a99fc0800b7a0f0944ac4c2382e3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 02:06:19 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 06:06:19 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565676379.69.0.939143006245.issue37760@roundup.psfhosted.org> miss-islington added the comment: New changeset b02e148a0d6e7a11df93a09ea5f4e1b0ad9b77b8 by Miss Islington (bot) in branch '3.8': bpo-37760: Mark all generated Unicode data headers as generated. (GH-15171) https://github.com/python/cpython/commit/b02e148a0d6e7a11df93a09ea5f4e1b0ad9b77b8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 02:33:48 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 13 Aug 2019 06:33:48 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1565678028.58.0.277818143818.issue37798@roundup.psfhosted.org> Raymond Hettinger added the comment: > Can I work on this issue? > It might be my first C module addition task for CPython. Yes. This issue would be a good place to start. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 02:51:42 2019 From: report at bugs.python.org (Batuhan) Date: Tue, 13 Aug 2019 06:51:42 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565679102.41.0.623731176345.issue37830@roundup.psfhosted.org> Change by Batuhan : ---------- pull_requests: +14968 pull_request: https://github.com/python/cpython/pull/15247 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 02:52:51 2019 From: report at bugs.python.org (Batuhan) Date: Tue, 13 Aug 2019 06:52:51 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565679171.69.0.895292824868.issue37830@roundup.psfhosted.org> Batuhan added the comment: serhiy can you review the solution i found? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 02:53:32 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 13 Aug 2019 06:53:32 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 In-Reply-To: <1565618378.34.0.81940050082.issue37833@roundup.psfhosted.org> Message-ID: <1565679212.43.0.552461985312.issue37833@roundup.psfhosted.org> Ronald Oussoren added the comment: I had a similar problem during EuroPython, but that was when I had anaconda on my machine. I've since removed it because generally don't use it but had it installed for a training session. I haven't tried to reproduce, but also don't run 10.14.6 yet (holding of rebooting due to too much active Terminal windows). I'll try to reproduce later this week on another machine. I get reports about this in the py2app repo as well, see , so this is not just something on a single machine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 03:00:06 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 13 Aug 2019 07:00:06 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 In-Reply-To: <1565618378.34.0.81940050082.issue37833@roundup.psfhosted.org> Message-ID: <1565679606.0.0.0762761818436.issue37833@roundup.psfhosted.org> Ronald Oussoren added the comment: A followup question: How can I determine the exact version of Tk? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 03:30:08 2019 From: report at bugs.python.org (Ned Deily) Date: Tue, 13 Aug 2019 07:30:08 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 In-Reply-To: <1565618378.34.0.81940050082.issue37833@roundup.psfhosted.org> Message-ID: <1565681408.05.0.216364430283.issue37833@roundup.psfhosted.org> Ned Deily added the comment: As far as I know, the best information you can get from Tk about version is the patch level which does not necessarily take into account builds from a dev repo or patched source. The easiest way to get that info from tkinter is to use test.pythoninfo: $ python3.7 -m test.pythoninfo [...] tkinter.TCL_VERSION: 8.6 tkinter.TK_VERSION: 8.6 tkinter.info_patchlevel: 8.6.8 [...] It may also be useful to ascertain which Tk libraries tkinter is linked with: $ python3.7 -c 'import _tkinter;print(_tkinter.__file__)' /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_tkinter.cpython-37m-darwin.so $ otool -L $(python3.7 -c 'import _tkinter;print(_tkinter.__file__)') /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_tkinter.cpython-37m-darwin.so: /Library/Frameworks/Python.framework/Versions/3.7/lib/libtcl8.6.dylib (compatibility version 8.6.0, current version 8.6.8) /Library/Frameworks/Python.framework/Versions/3.7/lib/libtk8.6.dylib (compatibility version 8.6.0, current version 8.6.8) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 03:36:11 2019 From: report at bugs.python.org (Ricardo Smits) Date: Tue, 13 Aug 2019 07:36:11 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 In-Reply-To: <1565681408.05.0.216364430283.issue37833@roundup.psfhosted.org> Message-ID: Ricardo Smits added the comment: Thanks! I was just looking how to send you all this info, so here it is: tkinter.TCL_VERSION: 8.6 tkinter.TK_VERSION: 8.6 tkinter.info_patchlevel: 8.6.8 $ python3.7 -c 'import _tkinter;print(_tkinter.__file__)' /anaconda3/envs/main/lib/python3.7/lib-dynload/_ tkinter.cpython-37m-darwin.so $ otool -L $(python3.7 -c 'import _tkinter;print(_tkinter.__file__)') /anaconda3/envs/main/lib/python3.7/lib-dynload/_ tkinter.cpython-37m-darwin.so: @rpath/libtcl8.6.dylib (compatibility version 8.6.0, current version 8.6.8) @rpath/libtk8.6.dylib (compatibility version 8.6.0, current version 8.6.8) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 03:52:27 2019 From: report at bugs.python.org (Greg Price) Date: Tue, 13 Aug 2019 07:52:27 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565682747.46.0.044155747259.issue37760@roundup.psfhosted.org> Change by Greg Price : ---------- pull_requests: +14969 pull_request: https://github.com/python/cpython/pull/15248 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 03:56:26 2019 From: report at bugs.python.org (Greg Price) Date: Tue, 13 Aug 2019 07:56:26 +0000 Subject: [issue32771] merge the underlying data stores of unicodedata and the str type In-Reply-To: <1517797199.65.0.467229070634.issue32771@psf.upfronthosting.co.za> Message-ID: <1565682986.41.0.29166999042.issue32771@roundup.psfhosted.org> Change by Greg Price : ---------- nosy: +Greg Price _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 04:02:29 2019 From: report at bugs.python.org (Ned Deily) Date: Tue, 13 Aug 2019 08:02:29 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 In-Reply-To: <1565618378.34.0.81940050082.issue37833@roundup.psfhosted.org> Message-ID: <1565683349.02.0.276608555034.issue37833@roundup.psfhosted.org> Ned Deily added the comment: OK, thanks, Ricardo. Since you appear to be using an Anaconda-supplied Tk, I suggest you open an issue or otherwise ask for help from the Conda project and, as necessary, the Tk folks. Without more info and unable to reproduce with other sources of Tk, there is next to nothing we can do here and the chances that this is a Python problem, rather than a Tk or macOS problem, is very slim. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 05:08:00 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Tue, 13 Aug 2019 09:08:00 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565687280.2.0.825559942565.issue37774@roundup.psfhosted.org> Jeroen Demeyer added the comment: > IHMO PGO compilation already defeats the purpose of these macros. That's certainly true. The question is whether we want to optimize also non-PGO builds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 05:25:17 2019 From: report at bugs.python.org (Aldwin Pollefeyt) Date: Tue, 13 Aug 2019 09:25:17 +0000 Subject: [issue12611] 2to3 crashes when converting doctest using reduce() In-Reply-To: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za> Message-ID: <1565688317.2.0.817217306533.issue12611@roundup.psfhosted.org> Change by Aldwin Pollefeyt : ---------- pull_requests: +14970 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15249 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 05:29:13 2019 From: report at bugs.python.org (Aldwin Pollefeyt) Date: Tue, 13 Aug 2019 09:29:13 +0000 Subject: [issue12611] 2to3 crashes when converting doctest using reduce() In-Reply-To: <1311349982.31.0.854147036767.issue12611@psf.upfronthosting.co.za> Message-ID: <1565688553.54.0.713771158928.issue12611@roundup.psfhosted.org> Change by Aldwin Pollefeyt : ---------- nosy: +aldwinaldwin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 05:36:43 2019 From: report at bugs.python.org (Netzeband) Date: Tue, 13 Aug 2019 09:36:43 +0000 Subject: [issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class Message-ID: <1565689003.91.0.0312877377737.issue37835@roundup.psfhosted.org> New submission from Netzeband : When evaluating the type-hints of an inner-class (a class defined inside a function scope), the forward declaration does not work correctly. In this case the typing.get_type_hints does not get the right namespace, thus the class-string specified is not found. When using the same syntax for a normal class (defined in global space) it works, or when using another class instead a forward declaration, also everything works. As a workaround one could pass the local namespace (locals()) from the function where the class has been defined in to typing.get_type_hints. However in normal situations the typing.get_type_hints call is deep in the call hierarchy to do some runtime type-checks and at this point only the reference to the function-object is existing and no-one is aware of the fact, that this is just a method defined in a inner class. >From the outside perspective one would expect, that typing.get_type_hints reacts the same, independent of the type of class. ---------- components: Library (Lib) files: typing_check.py messages: 349535 nosy: netbnd priority: normal severity: normal status: open title: typing.get_type_hints wrong namespace for forward-declaration of inner class type: behavior versions: Python 3.6, Python 3.7 Added file: https://bugs.python.org/file48539/typing_check.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 05:41:19 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Tue, 13 Aug 2019 09:41:19 +0000 Subject: [issue37836] Support .as_integer_ratio() in fractions.Fraction Message-ID: <1565689279.74.0.17922836333.issue37836@roundup.psfhosted.org> New submission from Jeroen Demeyer : Currently, the fractions.Fraction constructor accepts an .as_integer_ratio() method only for the specific types "float" and "Decimal". It would be good to support this for arbitrary classes. This is part of what was proposed in #37822, but without adding the math.operator() function. ---------- components: Library (Lib) messages: 349536 nosy: jdemeyer, mark.dickinson, rhettinger, serhiy.storchaka, stutzbach priority: normal severity: normal status: open title: Support .as_integer_ratio() in fractions.Fraction versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 05:42:12 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 13 Aug 2019 09:42:12 +0000 Subject: [issue31601] Availability of utimensat, futimens not checked correctly on macOS In-Reply-To: <1506493420.2.0.154975027568.issue31601@psf.upfronthosting.co.za> Message-ID: <1565689332.93.0.0422883055371.issue31601@roundup.psfhosted.org> Ronald Oussoren added the comment: I'd prefer a solution that uses symbols where the are available (weak linking). That way users on newer systems can use all functionality available there, without having multiple binaries. I've done this in the past for older macOS versions, but don't know how involved such patches would be for current versions of CPython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 06:23:05 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 10:23:05 +0000 Subject: [issue12447] ~True is not False In-Reply-To: <1309412742.21.0.0834751390952.issue12447@psf.upfronthosting.co.za> Message-ID: <1565691785.44.0.914714439756.issue12447@roundup.psfhosted.org> STINNER Victor added the comment: bpo-37831 has been marked as a duplicate of this issue. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 06:23:34 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Tue, 13 Aug 2019 10:23:34 +0000 Subject: [issue37256] urllib.request.Request documentation erroneously refers to the "final two" In-Reply-To: <1560366755.97.0.221740241329.issue37256@roundup.psfhosted.org> Message-ID: <1565691814.2.0.383138943616.issue37256@roundup.psfhosted.org> Sanyam Khurana added the comment: Thanks for the bug report Alan & for the PR Ngalim! I've checked the current docs and this is a valid bug. I've also reviewed the Pull request and it looks good to me. @Mariatta, @Senthil can you please have a look at this? Many thanks! ---------- nosy: +CuriousLearner, Mariatta, orsenthil versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 06:29:55 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 13 Aug 2019 10:29:55 +0000 Subject: [issue37837] add internal _PyLong_FromUnsignedChar() function Message-ID: <1565692195.8.0.862568192553.issue37837@roundup.psfhosted.org> New submission from Sergey Fedoseev : When compiled with default NSMALLPOSINTS, _PyLong_FromUnsignedChar() is significantly faster than other PyLong_From*(): $ python -m perf timeit -s "from collections import deque; consume = deque(maxlen=0).extend; b = bytes(2**20)" "consume(b)" --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 7.10 ms +- 0.02 ms /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 4.29 ms +- 0.03 ms Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 7.10 ms +- 0.02 ms -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 4.29 ms +- 0.03 ms: 1.66x faster (-40%) It's mostly useful for bytes/bytearray, but also can be used in several other places. ---------- components: Interpreter Core messages: 349540 nosy: sir-sigurd priority: normal severity: normal status: open title: add internal _PyLong_FromUnsignedChar() function type: performance versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 06:32:52 2019 From: report at bugs.python.org (Eryk Sun) Date: Tue, 13 Aug 2019 10:32:52 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565692372.15.0.0158953766685.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > Honestly, the only real problem I've seen is in applications that use > a reimplementation of spawn() rather than the UCRT's version (which > handles the reparse point jsut fine). I looked into this spawn problem. It's due to Cygwin's spawnve, which calls NtOpenFile to open the file, and then memory-maps it and reads the image header [1]. For an app-exec link, this fails with STATUS_IO_REPARSE_TAG_NOT_HANDLED, which is translated to Windows ERROR_CANT_ACCESS_FILE (1920). In turn, Cygwin translates this error to its to default errno value, EACCES. (The Windows CRT uses EINVAL as the default.) [1] https://github.com/cygwin/cygwin/blob/aa55d22cb55d67d7f77ee9d58f9016c42c3ee495/winsup/cygwin/spawn.cc#L1035 > Maybe it can just return bytes and let the caller do the parsing? It could parse out as much as possible and return a struct sequence: ReparseTag (int) ReparseGuid (string, or None for Microsoft tags) SymlinkFlags (int, SYMLINK_FLAG_RELATIVE) PrintName (string or None) SubstituteName (string or None) DataBuffer (bytes) Only the ReparseTag and DataBuffer fields would always be present. ReparseGuid would be present for non-Microsoft tags (i.e. bit 31 is unset). The result could maybe have one or more fields for the app-exec-link type. > This sounds like a good option to me, too. So that would suggest that > Modules/posixmodule.c in win32_xstat_impl would verify both > FILE_ATTRIBUTE_REPARSE_POINT and IO_REPARSE_TAG_SYMLINK? And if the > tag is different it'll return information about the reparse point > rather than the target? Maybe have two non-overlapping options, follow_symlinks and follow_nonlinks. The latter might be more sensible as a single option for lstat(), since it never follows symlinks. Then if either follow_symlinks or follow_nonlinks is false, stat has to open the reparse point and get the tag to determine whether it should reopen with reparsing enabled. The straight-forward way to get the tag is GetFileInformationByHandleEx: FileAttributeTagInfo. This should succeed if the file system supports reparse points. But still check for FILE_ATTRIBUTE_REPARSE_POINT in the attributes before trusting the tag value. If the call fails, assume it's not a reparse point and proceed to GetFileInformationByHandleW. Another tag to look for is IO_REPARSE_TAG_AF_UNIX (0x8000_0023). It's relatively new, so I haven't used it yet. I suppose it should be mapped S_IFSOCK in the stat result. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 06:34:33 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 13 Aug 2019 10:34:33 +0000 Subject: [issue37837] add internal _PyLong_FromUnsignedChar() function In-Reply-To: <1565692195.8.0.862568192553.issue37837@roundup.psfhosted.org> Message-ID: <1565692473.19.0.502908967958.issue37837@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- keywords: +patch pull_requests: +14971 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15251 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 06:42:59 2019 From: report at bugs.python.org (Netzeband) Date: Tue, 13 Aug 2019 10:42:59 +0000 Subject: [issue37838] typing.get_type_hints not working with forward-declaration and decorated functions Message-ID: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org> New submission from Netzeband : When decorating a function and using a forward declaration as type hint, the typing.get_type_hints function does not work anymore, since it cannot find the forward declared name in the namespace. After debugging I think, the typing.get_type_hints function is actually using the namespace of the decorator instead of the decorated function. When using a normal class type (no forward declaration) everything works fine and also when not using any decorator it works like expected. As a workaround, one could pass the local namespace to typing.get_type_hints. However in normal usecases this function is used for runtime typechecking in a deep call hierarchy. So one would normally not have access to the right local namespace, only to the function object itself. However there is another easy workaround. At least when using the functool.wraps method to create a function decorator. The decorated functions has a "__wrapped__" attribute, which references the original function. When using "typing.get_type_hints(function.__wrapped__)" instead of "typing.get_type_hints(function)", it works like expected. So maybe this could be built in into the get_type_hints method. ---------- components: Library (Lib) files: typing_check_wrapped.zip messages: 349542 nosy: netbnd priority: normal severity: normal status: open title: typing.get_type_hints not working with forward-declaration and decorated functions type: behavior versions: Python 3.6, Python 3.7 Added file: https://bugs.python.org/file48540/typing_check_wrapped.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 06:58:08 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 13 Aug 2019 10:58:08 +0000 Subject: [issue37838] typing.get_type_hints not working with forward-declaration and decorated functions In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org> Message-ID: <1565693888.36.0.801882540179.issue37838@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +gvanrossum, levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 07:00:09 2019 From: report at bugs.python.org (Will Bond) Date: Tue, 13 Aug 2019 11:00:09 +0000 Subject: [issue37839] makesetup Doesn't Handle Defines with Equal Sign Message-ID: <1565694009.91.0.692452487744.issue37839@roundup.psfhosted.org> New submission from Will Bond : Using 3.8.0b3 on macOS. I'm doing a custom compile with (heavy) modifications to Modules/Setup.local. Whenever I add a define rule to a module line that includes an equal sign, e.g.: _sqlite3 -DMODULE_NAME=_sqlite3 _sqlite/module.c _sqlite/cache.c _sqlite/connection.c _sqlite/cursor.c _sqlite/microprotocols.c _sqlite/prepare_protocol.c _sqlite/row.c _sqlite/statement.c _sqlite/util.c -I../env/include -I\$(srcdir)/Modules/_sqlite ../env/lib/libsqlite3.a makesetup appears to treat this as a Makefile variable definition, which places the rule in the wrong part of the Makefile. In my situation, this causes _sqlite3 to be compiled as a shared library instead of statically. I see this was peripherally reported at https://bugs.python.org/issue35184, but in that case the =1 was just dropped rather than solving the underlying issue. For many situations, dropping the =1 works, but in others it is not. Not that this is necessarily helpful, but I do know that this used to work with Python 3.3. ---------- messages: 349543 nosy: wbond priority: normal severity: normal status: open title: makesetup Doesn't Handle Defines with Equal Sign type: compile error versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 07:23:26 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 11:23:26 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565695406.13.0.647812709454.issue37774@roundup.psfhosted.org> STINNER Victor added the comment: > That's certainly true. The question is whether we want to optimize also non-PGO builds. If it's an optimization, can you show a benchmark to validate that it's really faster as expected? I tried for 6 months to run benchmarks without PGO and it was a loss of time: not building with PGO lead to random performances and so can easily lead to bad optimization decisions. See my article: https://vstinner.github.io/journey-to-stable-benchmark-deadcode.html I wrote a serie of articles: https://vstinner.readthedocs.io/benchmark.html#my-articles ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 07:50:02 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 13 Aug 2019 11:50:02 +0000 Subject: [issue37840] bytearray_getitem() handles negative index incorrectly Message-ID: <1565697002.74.0.85786305512.issue37840@roundup.psfhosted.org> New submission from Sergey Fedoseev : bytearray_getitem() adjusts negative index, though that's already done by PySequence_GetItem(). This makes PySequence_GetItem(bytearray(1), -2) to return 0 instead of raise IndexError. ---------- components: Interpreter Core messages: 349545 nosy: sir-sigurd priority: normal severity: normal status: open title: bytearray_getitem() handles negative index incorrectly type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 07:52:43 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 13 Aug 2019 11:52:43 +0000 Subject: [issue37840] bytearray_getitem() handles negative index incorrectly In-Reply-To: <1565697002.74.0.85786305512.issue37840@roundup.psfhosted.org> Message-ID: <1565697163.83.0.540730377336.issue37840@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- keywords: +patch pull_requests: +14972 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15250 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 08:18:54 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 12:18:54 +0000 Subject: [issue15010] unittest: _top_level_dir is incorrectly persisted between calls to different load_test methods In-Reply-To: <1338945643.44.0.808523506511.issue15010@psf.upfronthosting.co.za> Message-ID: <1565698734.71.0.870026796389.issue15010@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 08:23:29 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 12:23:29 +0000 Subject: [issue32771] merge the underlying data stores of unicodedata and the str type In-Reply-To: <1517797199.65.0.467229070634.issue32771@psf.upfronthosting.co.za> Message-ID: <1565699009.76.0.879436140962.issue32771@roundup.psfhosted.org> STINNER Victor added the comment: > This will remove awkward maneuvers like ast.c importing unicodedata in order to perform normalization. unicodedata is not needed by default. ast.c only imports unicodedata at the first non-ASCII identifier. If you application (and all dependencies) only use ASCII identifiers, unicodedata is never loaded. Loading it dynamically reduces the memory footprint. Raw measure on my Fedora 30 laptop: $ python3 Python 3.7.4 (default, Jul 9 2019, 16:32:37) [GCC 9.1.1 20190503 (Red Hat 9.1.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") VmRSS: 10236 kB >>> import unicodedata >>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") VmRSS: 10396 kB It uses 160 KiB of memory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 08:25:04 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 12:25:04 +0000 Subject: [issue32771] merge the underlying data stores of unicodedata and the str type In-Reply-To: <1517797199.65.0.467229070634.issue32771@psf.upfronthosting.co.za> Message-ID: <1565699104.7.0.275302376667.issue32771@roundup.psfhosted.org> STINNER Victor added the comment: Hum, I forget to mention that the module is compiled as a dynamically library, at least on Fedora: $ python3 Python 3.7.4 (default, Jul 9 2019, 16:32:37) [GCC 9.1.1 20190503 (Red Hat 9.1.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import unicodedata >>> unicodedata It's a big file: 1.1 MiB. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 08:33:28 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 12:33:28 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565699608.27.0.200382484317.issue37760@roundup.psfhosted.org> STINNER Victor added the comment: $ find -name "*db.h" ./Modules/unicodedata_db.h ./Modules/unicodename_db.h ./Objects/unicodetype_db.h For .gitattributes, I would prefer to use unicode*_db.h pattern rather than "a generic" *_db.h, to avoid masking other potential file called "something_db.h" in the future in GitHub. But it's not really an issue right now ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 08:35:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 12:35:15 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565699715.58.0.283787314068.issue37760@roundup.psfhosted.org> STINNER Victor added the comment: "from typing import *" I like to run pyflakes time to time on the Python code base. Please avoid "import *" since it prevents pyflakes (and other code analyzers) to find bugs. Example: $ pyflakes Tools/unicode/makeunicodedata.py Tools/unicode/makeunicodedata.py:35: 'from typing import *' used; unable to detect undefined names Tools/unicode/makeunicodedata.py:921: 'Iterator' may be undefined, or defined from star imports: typing Tools/unicode/makeunicodedata.py:921: 'List' may be undefined, or defined from star imports: typing Tools/unicode/makeunicodedata.py:921: 'Iterator' may be undefined, or defined from star imports: typing ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 08:49:27 2019 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 13 Aug 2019 12:49:27 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1565699715.58.0.283787314068.issue37760@roundup.psfhosted.org> Message-ID: Marc-Andre Lemburg added the comment: BTW: Since when do we use type annotations in Python's stdlib ? ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 08:51:03 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 12:51:03 +0000 Subject: [issue16958] The sqlite3 context manager does not work with isolation_level=None In-Reply-To: <1358124405.04.0.0310758361359.issue16958@psf.upfronthosting.co.za> Message-ID: <1565700663.44.0.0878917994949.issue16958@roundup.psfhosted.org> Change by STINNER Victor : ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 08:51:22 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Tue, 13 Aug 2019 12:51:22 +0000 Subject: [issue37837] add internal _PyLong_FromUnsignedChar() function In-Reply-To: <1565692195.8.0.862568192553.issue37837@roundup.psfhosted.org> Message-ID: <1565700682.87.0.474791780127.issue37837@roundup.psfhosted.org> Jeroen Demeyer added the comment: Maybe an even better idea would be to partially inline PyLong_FromLong(). If the check for small ints in PyLong_FromLong() would be inlined, then the compiler could optimize those checks. This would benefit all users of PyLong_FromLong() without code changes. ---------- nosy: +jdemeyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:00:14 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Tue, 13 Aug 2019 13:00:14 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565701214.39.0.242728515049.issue37774@roundup.psfhosted.org> Jeroen Demeyer added the comment: > If it's an optimization, can you show a benchmark to validate that it's really faster as expected? Yes, I did test it. I didn't save the results, but I can redo them if you want. If you plan to reject the issue anyway, there is no point. > not building with PGO lead to random performances I would expect that Py_LIKELY/Py_UNLIKELY helps with this. If the compiler doesn't have probability information, it guesses. This can cause unrelated changes to change the heuristics used by the compiler, impacting the performance of some piece of code. With Py_LIKELY/Py_UNLIKELY, the code generated by the compiler should be more stable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:09:51 2019 From: report at bugs.python.org (Kim Gustyr) Date: Tue, 13 Aug 2019 13:09:51 +0000 Subject: [issue36077] Inheritance dataclasses fields and default init statement In-Reply-To: <1550838433.8.0.658564691536.issue36077@roundup.psfhosted.org> Message-ID: <1565701791.33.0.568846612468.issue36077@roundup.psfhosted.org> Change by Kim Gustyr : ---------- nosy: +kgustyr _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:24:04 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 13 Aug 2019 13:24:04 +0000 Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4 given) In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za> Message-ID: <1565702644.09.0.550522313923.issue25299@roundup.psfhosted.org> Joannah Nanjekye added the comment: paul.j3, The fix looks promising. Do you want to open a PR with this fix? ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:32:28 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 13 Aug 2019 13:32:28 +0000 Subject: [issue20861] datetime argument handling inconsistent; should accept logical integers, not coercible values In-Reply-To: <1394149613.74.0.409491406702.issue20861@psf.upfronthosting.co.za> Message-ID: <1565703148.06.0.737638904507.issue20861@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:34:25 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 13 Aug 2019 13:34:25 +0000 Subject: [issue1615158] POSIX capabilities support Message-ID: <1565703265.37.0.605136264061.issue1615158@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:35:21 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 13:35:21 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565703321.89.0.172448982479.issue37774@roundup.psfhosted.org> STINNER Victor added the comment: > I would expect that Py_LIKELY/Py_UNLIKELY helps with this. Well, PGO is made of many optimizations, not only help branch prediction. For example, it detects hot code and tries to put functions which call them each other close in memory to enhance the CPU instruction cache efficiency. I tried to annotate "hot" functions but I failed to get reproducible performance results. commit c6944e7edcacc8960170719623c325aefaf23cac Author: Victor Stinner Date: Fri Nov 11 02:13:35 2016 +0100 Issue #28618: Make hot functions using __attribute__((hot)) When Python is not compiled with PGO, the performance of Python on call_simple and call_method microbenchmarks depend highly on the code placement. In the worst case, the performance slowdown can be up to 70%. The GCC __attribute__((hot)) attribute helps to keep hot code close to reduce the risk of such major slowdown. This attribute is ignored when Python is compiled with PGO. The following functions are considered as hot according to statistics collected by perf record/perf report: * _PyEval_EvalFrameDefault() * call_function() * _PyFunction_FastCall() * PyFrame_New() * frame_dealloc() * PyErr_Occurred() But my change didn't work: "Sadly, it seems like I was just lucky when adding __attribute__((hot)) fixed the issue, because call_method is slow again! (...) (+51%)" https://bugs.python.org/issue28618#msg281459 PGO is like black magic for me :-) Note: Since this change, pyperformance evolved: I removed call_method microbenchmark. It was too instable for various reasons. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:40:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 13:40:18 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565703618.7.0.51675947821.issue37774@roundup.psfhosted.org> STINNER Victor added the comment: Another example to explain my concern. In the Linux kernel, list macros used to prefetch next items: ?(...) So the conclusion is: prefetches are absolutely toxic, even if the NULL ones are excluded.? https://lwn.net/Articles/444336/ The lesson is that we should not let developers tune the compiler: let the CPU do that for you :-) For example, CPUs have evolved heuristics to prefetch data for you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:49:00 2019 From: report at bugs.python.org (Tal Einat) Date: Tue, 13 Aug 2019 13:49:00 +0000 Subject: [issue37821] IDLE shell uses wrong namespace for completions In-Reply-To: <1565522228.88.0.811193115322.issue37821@roundup.psfhosted.org> Message-ID: <1565704140.79.0.328162421088.issue37821@roundup.psfhosted.org> Tal Einat added the comment: Terry, many thanks for the clarifications! > The intended behavior is to complete if at all possible. I can see the point in that. > What is odd to me is that you seem happy using the more numerous non-user IDLE imports when there is no Shell. The alternative would just be completing in an empty namespace, which would be completely useless. I do agree that having a shell should increase the available modules etc. available for completion. FWIW I brought this up trying the dict-key completions in the shell with `globals()`, and got very surprising results. Perhaps we should differentiate between completions in the shell vs. when editing a file. In the shell, having completions for things not actually available is weird IMO. In the editor it makes more sense. Or perhaps we should really go the route of 18766 and try to make all available modules available for completions. I really dislike the arbitrary availability of only certain modules for completion. That would likely be a *huge* undertaking, though, and I don't think it's worth it. Maybe restrict this to just stdlib modules, and/or use lazy (on demand) importing. Finally, we can also decide that the current behavior is what we want. It's there, documented, and normally not very surprising. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:49:57 2019 From: report at bugs.python.org (Tal Einat) Date: Tue, 13 Aug 2019 13:49:57 +0000 Subject: [issue37821] IDLE shell uses wrong namespace for completions In-Reply-To: <1565522228.88.0.811193115322.issue37821@roundup.psfhosted.org> Message-ID: <1565704197.01.0.393073627672.issue37821@roundup.psfhosted.org> Change by Tal Einat : ---------- Removed message: https://bugs.python.org/msg349556 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:50:42 2019 From: report at bugs.python.org (Tal Einat) Date: Tue, 13 Aug 2019 13:50:42 +0000 Subject: [issue37821] IDLE shell uses wrong namespace for completions In-Reply-To: <1565522228.88.0.811193115322.issue37821@roundup.psfhosted.org> Message-ID: <1565704242.72.0.820170589662.issue37821@roundup.psfhosted.org> Tal Einat added the comment: Terry, many thanks for the clarifications! > The intended behavior is to complete if at all possible. I can see the point in that. > What is odd to me is that you seem happy using the more numerous non-user IDLE imports when there is no Shell. The alternative would just be completing in an empty namespace, which would be completely useless. I do agree that having a shell should increase the available modules etc. available for completion. FWIW I brought this up trying the dict-key completions in the shell with `globals()[` and got surprising results. Perhaps we should differentiate between completions in the shell vs. when editing a file. In the shell, having completions for things not actually available is weird IMO. In the editor it makes more sense. Or perhaps we should really go the route of issue #18766 and try to make all available modules available for completions. I really dislike the arbitrary availability of only certain modules for completion. That would likely be a *huge* undertaking, though, and I don't think it's worth it. Maybe restrict this to just stdlib modules, and/or use lazy (on demand) importing. Finally, we can also decide that the current behavior is what we want. It's there, documented, and normally not very surprising. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:54:09 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 13 Aug 2019 13:54:09 +0000 Subject: [issue20861] datetime argument handling inconsistent; should accept logical integers, not coercible values In-Reply-To: <1394149613.74.0.409491406702.issue20861@psf.upfronthosting.co.za> Message-ID: <1565704449.58.0.965565864651.issue20861@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:56:00 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 13 Aug 2019 13:56:00 +0000 Subject: [issue20861] datetime argument handling inconsistent; should accept logical integers, not coercible values In-Reply-To: <1394149613.74.0.409491406702.issue20861@psf.upfronthosting.co.za> Message-ID: <1565704560.77.0.225041375362.issue20861@roundup.psfhosted.org> Joannah Nanjekye added the comment: Could be related to some discussions in this PR: https://github.com/python/cpython/pull/14842 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 09:57:29 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Tue, 13 Aug 2019 13:57:29 +0000 Subject: [issue20861] datetime argument handling inconsistent; should accept logical integers, not coercible values In-Reply-To: <1394149613.74.0.409491406702.issue20861@psf.upfronthosting.co.za> Message-ID: <1565704649.41.0.117403930571.issue20861@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 10:03:34 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 14:03:34 +0000 Subject: [issue20861] datetime argument handling inconsistent; should accept logical integers, not coercible values In-Reply-To: <1394149613.74.0.409491406702.issue20861@psf.upfronthosting.co.za> Message-ID: <1565705014.49.0.0215826268246.issue20861@roundup.psfhosted.org> STINNER Victor added the comment: See also bpo-35707. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 10:03:43 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 14:03:43 +0000 Subject: [issue35707] time.sleep() should support objects with __float__ In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org> Message-ID: <1565705023.46.0.0966305438825.issue35707@roundup.psfhosted.org> STINNER Victor added the comment: See also bpo-20861. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 10:12:17 2019 From: report at bugs.python.org (flying sheep) Date: Tue, 13 Aug 2019 14:12:17 +0000 Subject: [issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio In-Reply-To: <1526401266.56.0.682650639539.issue33523@psf.upfronthosting.co.za> Message-ID: <1565705537.32.0.678686506106.issue33523@roundup.psfhosted.org> flying sheep added the comment: There?s this monkeypatching solution: https://pypi.org/project/nest-asyncio/ But yes, it?s a very practical problem that you can?t call async code from sync code that?s being called from async code. ---------- nosy: +flying sheep _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 10:26:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 14:26:25 +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: <1565706385.68.0.496114678154.issue17576@roundup.psfhosted.org> STINNER Victor added the comment: It started to write a new issue, but then I found this issue issue (created in 2013!) which is still open. So let me write my comment here instead. The code to convert a number to an integer is quite complex in Python. There are *many* ways to do that and each way has subtle behavior differences (ex: __index__ vs __int__). Python tolerates some behavior which lead to even more confusion. For example, some functions explicitly reject the float type but accept Decimal: * bpo-20861 * bpo-35707 PyLong_Long(obj) calls type(obj).__index__() if it's defined, but it accepts subtypes of int, not only exactly the int type (type(x) == int). This feature is deprecated since Python 3.3 (released in 2012), since this change: commit 31a655411a79b00517cdcd0a2752824d183db792 Author: Serhiy Storchaka Date: Wed Dec 11 21:07:54 2013 +0200 Issue #17576: Deprecation warning emitted now when __int__() or __index__() return not int instance. Introduced _PyLong_FromNbInt() and refactored PyLong_As*() functions. I propose to now fail with an exception if __int__() or __index__() return type is not exactly int. Note: My notes on Python numbers: https://pythondev.readthedocs.io/numbers.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 10:29:33 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Tue, 13 Aug 2019 14:29:33 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565706573.48.0.531490373823.issue37774@roundup.psfhosted.org> Jeroen Demeyer added the comment: We're not talking about prefetching here. The Py_LIKELY/Py_UNLIKELY macros only affect which of the two code paths in a branch is the "default" one, i.e. the one not involving a jmp. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 10:35:36 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Tue, 13 Aug 2019 14:35:36 +0000 Subject: [issue20861] datetime argument handling inconsistent; should accept logical integers, not coercible values In-Reply-To: <1394149613.74.0.409491406702.issue20861@psf.upfronthosting.co.za> Message-ID: <1565706936.82.0.919158511093.issue20861@roundup.psfhosted.org> Jeroen Demeyer added the comment: This is essentially a duplicate of #36048. The example is now deprecated: >>> from decimal import Decimal >>> from datetime import datetime >>> datetime(Decimal("2000.5"), 1, 2) :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(2000, 1, 2, 0, 0) So I think that this can be closed. ---------- nosy: +jdemeyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 10:38:28 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Aug 2019 14:38:28 +0000 Subject: [issue37838] typing.get_type_hints not working with forward-declaration and decorated functions In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org> Message-ID: <1565707108.51.0.869869936301.issue37838@roundup.psfhosted.org> Guido van Rossum added the comment: Using `__wrapped__` if present sounds like a good idea. Ivan, what do you think? Netzeband, have you considered submitting a PR with the necessary changes (and tests and docs)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 10:38:36 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 13 Aug 2019 14:38:36 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565707116.01.0.235270323172.issue25172@roundup.psfhosted.org> Change by Srinivas Nyayapati : ---------- pull_requests: +14973 pull_request: https://github.com/python/cpython/pull/15252 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 10:42:42 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 13 Aug 2019 14:42:42 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565707362.88.0.290570596829.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: I submitted a new PR for the Windows test case. Please take a look. Also how do I attach the label "skip news" to this new PR? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 10:44:35 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Tue, 13 Aug 2019 14:44:35 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565707475.2.0.590992526327.issue37774@roundup.psfhosted.org> Jeroen Demeyer added the comment: I claim that adding Py_LIKELY/Py_UNLIKELY will reduce the performance randomness of non-PGO builds. So it would be strange to use that randomness as an argument *against* this patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 10:57:51 2019 From: report at bugs.python.org (Paul Moore) Date: Tue, 13 Aug 2019 14:57:51 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565708271.61.0.524344916572.issue25172@roundup.psfhosted.org> Paul Moore added the comment: I added the label for you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 10:59:04 2019 From: report at bugs.python.org (Paul Moore) Date: Tue, 13 Aug 2019 14:59:04 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565708344.53.0.844248445966.issue25172@roundup.psfhosted.org> Paul Moore added the comment: To clarify, I think adding the label needs core dev (or maybe triager) rights on github, so I don't think it's something you can do yourself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 11:24:08 2019 From: report at bugs.python.org (Ethan Furman) Date: Tue, 13 Aug 2019 15:24:08 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565709848.5.0.0810334993013.issue37830@roundup.psfhosted.org> Ethan Furman added the comment: My apologies if I missed something, but do we have a consensus on the desired solution? My understanding of `try/finally` is that whatever happens in the `finally` clause should: - always happen - win any conflicts with `try` clause For example: try: a = 2 finally: a = 3 print(a) # 3 and def f(): try: return 5 finally: return 7 print(f()) # 7 So it seems like the ideal solution to: def mult(thing): print(thing*2) return thing * 2 def simple(): for number in range(2): try: return mult(number) finally: continue print(simple()) would be: 0 2 None ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 11:37:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 15:37:15 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565710635.75.0.509899777639.issue37774@roundup.psfhosted.org> STINNER Victor added the comment: > We're not talking about prefetching here. The Py_LIKELY/Py_UNLIKELY macros only affect which of the two code paths in a branch is the "default" one, i.e. the one not involving a jmp. I know. My point about prefetching is that if we provide a way to developers to tune the compiler, they will use it, but it can lead the a performance regression whereas not using these tools would lead to such issue. > I claim that adding Py_LIKELY/Py_UNLIKELY will reduce the performance randomness of non-PGO builds. So it would be strange to use that randomness as an argument *against* this patch. It's right that Py_LIKELY/Py_UNLIKELY should make performance more reliable. My question is if it is safe to let developers "abuse" it. If these macros are misused, they can lead to a performance regression. I'm not sure that Py_LIKELY/Py_UNLIKELY is always more performant than not using it. For example, if you mark the error path as unlikely: this path will become slower. If the error path is taken "frequently" enough, the slowdown can become significant overall. It's tricky to decide if a code path is likely or not. I would be ok to use Py_UNLIKELY for sanity checks which raise SystemError: these code paths must never be taken in a valid code. I'm more in favor of simply removing these runtime checks in release mode, but that's a different issue :-) (bpo-37406) I'm not sure about judging if the error case raising an exception really deserve a Py_UNLIKELY. Maybe I would be more comfortable if you would split the PR into multiple parts. One PR to add the macros. Then one PR per kind of modified tests. For example, "if (Py_UNLIKELY(tstate->use_tracing))" in ceval.c sounds reasonable, but I would prefer to have the opinion of other core devs. About the macros, I would prefer to make it private to not promote it. It should also have a good explanation why it's better to not use it, except if you really well understand what you do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 11:37:46 2019 From: report at bugs.python.org (Anthony Sottile) Date: Tue, 13 Aug 2019 15:37:46 +0000 Subject: [issue8243] curses writing to window's bottom right position raises: `_curses.error: addstr() returned ERR' In-Reply-To: <1352121880.55.0.191535515397.issue8243@psf.upfronthosting.co.za> Message-ID: <1565710666.2.0.00764905591949.issue8243@roundup.psfhosted.org> Anthony Sottile added the comment: In case it helps someone else, `insstr` seems to not have this limitation ---------- nosy: +Anthony Sottile _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 11:43:19 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 13 Aug 2019 15:43:19 +0000 Subject: [issue36266] Which module could not be found? In-Reply-To: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org> Message-ID: <1565710999.0.0.517867394519.issue36266@roundup.psfhosted.org> Srinivas Nyayapati added the comment: can a reviewer please take a look to my PR? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 11:48:45 2019 From: report at bugs.python.org (egaudry) Date: Tue, 13 Aug 2019 15:48:45 +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: <1565711325.86.0.102489190237.issue13501@roundup.psfhosted.org> egaudry added the comment: Hi, I think that there are some issues in the last patch (0001-Build-or-disable-readline-module-with-Editline.patch) made available. For instance, the using_libedit_emulation variable should be protected by DETECT_EDITLINE ifdef (and not SUPPORT_EDITLINE). And the setup.py file mentioned a 'readline_lib' string instead of the readline_lib variable. I am interested by being able to build python without readline but libedit instead too. ---------- nosy: +egaudry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 11:49:27 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Aug 2019 15:49:27 +0000 Subject: [issue37841] Python store app launcher has dependency on msvcp140.dll Message-ID: <1565711367.34.0.212877315326.issue37841@roundup.psfhosted.org> New submission from Steve Dower : A change made to the python_uwp.vcxproj (or more likely the .cpp file) has introduced a runtime dependency on msvcp140.dll. As we don't distribute this dependency, and it is not always installed by default, we should statically link it instead. ---------- assignee: steve.dower components: Windows messages: 349575 nosy: lukasz.langa, paul.moore, steve.dower, tim.golden, zach.ware priority: release blocker severity: normal stage: needs patch status: open title: Python store app launcher has dependency on msvcp140.dll type: crash versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 11:50:21 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 15:50:21 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565711421.09.0.686457312418.issue37774@roundup.psfhosted.org> STINNER Victor added the comment: Few more links about likely/__builtin_expect: * GCC documentation says: "In general, you should prefer to use actual profile feedback for this (-fprofile-arcs), as programmers are notoriously bad at predicting how their programs actually perform." https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html * https://softwareengineering.stackexchange.com/questions/188853/how-much-usage-of-likely-and-unlikely-macros-is-too-much "If you're writing for x86/x64 (and are not using 20-year-old CPUs), the performance gain from using __builtin_expect() will be negligible if any." * http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html "This optimized version [PGO] runs significantly faster (...) than our version that used __builtin_expect()." [When __builtin_expect() is misused] "In this case, unsurprisingly, we made each check run slower (...)" * https://stackoverflow.com/questions/109710/how-do-the-likely-unlikely-macros-in-the-linux-kernel-work-and-what-is-their-ben "Like all such performance optimisations you should only do it after extensive profiling to ensure the code really is in a bottleneck (...)" * https://stackoverflow.com/questions/10922607/gcc-likely-unlikely-macro-usage ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 11:52:44 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 15:52:44 +0000 Subject: [issue20861] datetime argument handling inconsistent; should accept logical integers, not coercible values In-Reply-To: <1394149613.74.0.409491406702.issue20861@psf.upfronthosting.co.za> Message-ID: <1565711564.47.0.531504424492.issue20861@roundup.psfhosted.org> STINNER Victor added the comment: This issue has been fixed in Python 3.3 by bpo-17576 which started to emit the DeprecationWarning. ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 12:05:34 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Aug 2019 16:05:34 +0000 Subject: [issue37841] Python store app launcher has dependency on msvcp140.dll In-Reply-To: <1565711367.34.0.212877315326.issue37841@roundup.psfhosted.org> Message-ID: <1565712334.83.0.945899380152.issue37841@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch pull_requests: +14974 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15253 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 12:09:46 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Aug 2019 16:09:46 +0000 Subject: [issue37830] continue in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565712586.33.0.412989984265.issue37830@roundup.psfhosted.org> Serhiy Storchaka added the comment: Batuhan, unfortunately your second solution does not work too, because continue and break can be conditional. For example: def simple(x): for number in range(2): try: return number finally: if x: continue print(simple(0)) print(simple(1)) It should print: 0 None Ethan, your understanding is correct. ---------- keywords: +3.8regression -patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 12:18:41 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Aug 2019 16:18:41 +0000 Subject: [issue37830] continue and break in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565713121.26.0.516225895032.issue37830@roundup.psfhosted.org> Serhiy Storchaka added the comment: Note, that we have a regression in 3.8. There is a use case for "break" in "finally", and such code is even used in the stdlib. And who know in what third-party code it is used. In specific circumstances (see msg349513) it now can cause a crash. Other example: import contextlib def simple(): with contextlib.nullcontext(): for number in range(2): try: return number finally: break simple() It just raise an exception in 3.8, not crash: Traceback (most recent call last): File "", line 1, in File "", line 7, in simple TypeError: 'range_iterator' object is not callable ---------- stage: patch review -> title: continue in finally with return in try results with segfault -> continue and break in finally with return in try results with segfault _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 12:22:23 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Tue, 13 Aug 2019 16:22:23 +0000 Subject: [issue37838] typing.get_type_hints not working with forward-declaration and decorated functions In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org> Message-ID: <1565713343.15.0.913347004544.issue37838@roundup.psfhosted.org> Ivan Levkivskyi added the comment: > Using `__wrapped__` if present sounds like a good idea. Yeah, I like this idea, this will likely cover most use cases (since most people actually do use @wraps). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 12:28:22 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Aug 2019 16:28:22 +0000 Subject: [issue37838] typing.get_type_hints not working with forward-declaration and decorated functions In-Reply-To: <1565713343.15.0.913347004544.issue37838@roundup.psfhosted.org> Message-ID: Guido van Rossum added the comment: Maybe we should tag this issue "newcomer friendly"? It seems a pretty open and shut case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 12:37:28 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 13 Aug 2019 16:37:28 +0000 Subject: [issue37842] Initialize Py_buffer variables more efficiently Message-ID: <1565714248.3.0.317246195617.issue37842@roundup.psfhosted.org> New submission from Sergey Fedoseev : Argument Clinic generates `{NULL, NULL}` initializer for Py_buffer variables. Such initializer zeroes all Py_buffer members, but as I understand only `obj` and `buf` members are really had to be initialized. Avoiding unneeded initialization provides tiny speed-up: $ python -m perf timeit -s "replace = b''.replace" "replace(b'', b'')" --compare-to=../cpython-master/venv/bin/python --duplicate=1000 /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 43.0 ns +- 0.5 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 41.8 ns +- 0.4 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 43.0 ns +- 0.5 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 41.8 ns +- 0.4 ns: 1.03x faster (-3%) ---------- components: Argument Clinic messages: 349582 nosy: larry, sir-sigurd priority: normal severity: normal status: open title: Initialize Py_buffer variables more efficiently type: performance versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 12:38:30 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Tue, 13 Aug 2019 16:38:30 +0000 Subject: [issue37842] Initialize Py_buffer variables more efficiently In-Reply-To: <1565714248.3.0.317246195617.issue37842@roundup.psfhosted.org> Message-ID: <1565714310.76.0.766106440847.issue37842@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- keywords: +patch pull_requests: +14975 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15254 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 12:40:24 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Tue, 13 Aug 2019 16:40:24 +0000 Subject: [issue21109] tarfile: Traversal attack vulnerability In-Reply-To: <1396253659.12.0.842636239516.issue21109@psf.upfronthosting.co.za> Message-ID: <1565714424.59.0.0290002983747.issue21109@roundup.psfhosted.org> Ashwin Ramaswami added the comment: SafeTarFile does not pass the existing tests, mainly because the existing file Lib/test/tarfiletestdata/testtar.tar seems to be "unsafe", producing errors like these: tarfile.SecurityError: : block device tarfile.SecurityError: : duplicate name It seems like the solution here is to remove block devices and duplicate names from testtar.tar. However, is this desirable -- do we need to keep these in for the tests for TarFile? ---------- versions: +Python 3.9 -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 12:42:57 2019 From: report at bugs.python.org (paul j3) Date: Tue, 13 Aug 2019 16:42:57 +0000 Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4 given) In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za> Message-ID: <1565714577.83.0.575563129688.issue25299@roundup.psfhosted.org> paul j3 added the comment: I'm not set up to work with the current development distribution (via github). All my proposed patches are diffs for earlier repos. Paul ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:04:27 2019 From: report at bugs.python.org (Richard Jayne) Date: Tue, 13 Aug 2019 17:04:27 +0000 Subject: [issue37843] CGIHTTPRequestHandler does not take args.directory in constructor Message-ID: <1565715867.88.0.342712762269.issue37843@roundup.psfhosted.org> New submission from Richard Jayne : In Lib/http/server.py if args.cgi: handler_class = CGIHTTPRequestHandler else: handler_class = partial(SimpleHTTPRequestHandler, directory=args.directory) Notice that CGIHTTPRequestHandler does not accept directory=args.directory, and so the option does not work with the --cgi option. ---------- components: Extension Modules messages: 349585 nosy: rjayne priority: normal severity: normal status: open title: CGIHTTPRequestHandler does not take args.directory in constructor type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:11:35 2019 From: report at bugs.python.org (Brett Cannon) Date: Tue, 13 Aug 2019 17:11:35 +0000 Subject: [issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule In-Reply-To: <1565473572.7.0.81062665759.issue37813@roundup.psfhosted.org> Message-ID: <1565716295.07.0.94402613467.issue37813@roundup.psfhosted.org> Change by Brett Cannon : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:17:46 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 13 Aug 2019 17:17:46 +0000 Subject: [issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule In-Reply-To: <1565473572.7.0.81062665759.issue37813@roundup.psfhosted.org> Message-ID: <1565716666.71.0.810240687509.issue37813@roundup.psfhosted.org> Barry A. Warsaw added the comment: I personally don't think we need to change this. C and Python are different, and the PEP 7 rules have been in place for ages. +Guido ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:27:48 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Aug 2019 17:27:48 +0000 Subject: [issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule In-Reply-To: <1565473572.7.0.81062665759.issue37813@roundup.psfhosted.org> Message-ID: <1565717268.37.0.572976099773.issue37813@roundup.psfhosted.org> Serhiy Storchaka added the comment: PEP 8 contains contradictory examples. https://www.python.org/dev/peps/pep-0008/#indentation > # No extra indentation. > if (this_is_one_thing and > that_is_another_thing): > do_something() > > # Add a comment, which will provide some distinction in editors > # supporting syntax highlighting. > if (this_is_one_thing and > that_is_another_thing): > # Since both conditions are true, we can frobnicate. > do_something() > > # Add some extra indentation on the conditional continuation line. > if (this_is_one_thing > and that_is_another_thing): > do_something() > > (Also see the discussion of whether to break before or after binary > operators below.) (It was already reported in other issue.) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:28:10 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Aug 2019 17:28:10 +0000 Subject: [issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule In-Reply-To: <1565473572.7.0.81062665759.issue37813@roundup.psfhosted.org> Message-ID: <1565717290.69.0.034558826111.issue37813@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- versions: -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:33:32 2019 From: report at bugs.python.org (Greg Price) Date: Tue, 13 Aug 2019 17:33:32 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565717612.36.0.560872523448.issue37760@roundup.psfhosted.org> Greg Price added the comment: > I like to run pyflakes time to time on the Python code base. Please avoid "import *" since it prevents pyflakes (and other code analyzers) to find bugs. Ah fair enough, thanks! Pushed that change to the next/current PR, GH-15248. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:34:10 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Aug 2019 17:34:10 +0000 Subject: [issue37841] Python store app launcher has dependency on msvcp140.dll In-Reply-To: <1565711367.34.0.212877315326.issue37841@roundup.psfhosted.org> Message-ID: <1565717650.83.0.0328207402926.issue37841@roundup.psfhosted.org> Steve Dower added the comment: New changeset b0dace3e979381426385c551b116d0f1434096ee by Steve Dower in branch 'master': bpo-37841: Remove python_uwp dependency on msvcp140.dll (GH-15253) https://github.com/python/cpython/commit/b0dace3e979381426385c551b116d0f1434096ee ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:34:42 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 17:34:42 +0000 Subject: [issue37841] Python store app launcher has dependency on msvcp140.dll In-Reply-To: <1565711367.34.0.212877315326.issue37841@roundup.psfhosted.org> Message-ID: <1565717682.35.0.950374877913.issue37841@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14976 pull_request: https://github.com/python/cpython/pull/15257 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:38:07 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 13 Aug 2019 17:38:07 +0000 Subject: [issue37583] Got a 113 error when running the test_socket In-Reply-To: <1563006871.17.0.626459715079.issue37583@roundup.psfhosted.org> Message-ID: <1565717887.47.0.819812773102.issue37583@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 1ac2a83f30312976502fda042db5ce18d10ceec2 by Victor Stinner (Hai Shi) in branch 'master': bpo-37583: Add err 113 to support.get_socket_conn_refused_errs() (GH-14729) https://github.com/python/cpython/commit/1ac2a83f30312976502fda042db5ce18d10ceec2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:38:12 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 17:38:12 +0000 Subject: [issue37583] Got a 113 error when running the test_socket In-Reply-To: <1563006871.17.0.626459715079.issue37583@roundup.psfhosted.org> Message-ID: <1565717892.94.0.709064303054.issue37583@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14977 pull_request: https://github.com/python/cpython/pull/15258 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:38:21 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Aug 2019 17:38:21 +0000 Subject: [issue37841] Python store app launcher has dependency on msvcp140.dll In-Reply-To: <1565711367.34.0.212877315326.issue37841@roundup.psfhosted.org> Message-ID: <1565717901.99.0.528976668234.issue37841@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:39:24 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Aug 2019 17:39:24 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565717964.79.0.934109145372.issue37834@roundup.psfhosted.org> Steve Dower added the comment: > I looked into this spawn problem. It's due to Cygwin's spawnve, which calls NtOpenFile to open the file, and then memory-maps it and reads the image header [1]. Great, that's roughly what I suspected. Unfortunately, I've been told that looking into Cygwin's (GPL'd) code myself is going to cost me two weeks of dev work ("cooling off" period), so someone else will have to help them fix it. > It could parse out as much as possible and return a struct sequence TBH, I feel like that's more work than is worth us doing for something that will be relatively rarely used, will live in the stdlib, and is obviously something that will become outdated as Microsoft adds new reparse points. If we return the parsed data as opaque bytes then someone can write a simple PyPI package to extract the contents. (Presumably the reparse tag will have come from stat() already.) > Maybe have two non-overlapping options, follow_symlinks and follow_nonlinks I read this suggestion the first time and I think it would send the message that we are more capable than we really are :) In theory, we can't follow any reparse point that isn't documented as being followable and provides the target name is a stable, documented manner. The appexec links don't do this (I just looked at the returned buffer), so we really should just not follow them. They exist solely so that CreateProcess internally returns a unique error code that can be handled without impacting regular process start, which means we *don't* want to follow them. Again, if someone writes the PyPI package to parse all known reparse points, they can do that. Now, directory junctions are far more interesting. My gut feel is that we should treat them the same as symlinks (with respect to stat vs. lstat) for consistency, but I'll gladly defer to you (Eryk) for the edge cases that may introduce. --- My plan for PR 15231 is: * make os.stat only follow symlinks and junctions * make os.readlink only read symlinks and junctions * add st_reparse_tag field to os.stat ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:46:47 2019 From: report at bugs.python.org (Greg Price) Date: Tue, 13 Aug 2019 17:46:47 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565718407.22.0.150447364918.issue37760@roundup.psfhosted.org> Greg Price added the comment: > BTW: Since when do we use type annotations in Python's stdlib ? Hmm, interesting question! At a quick grep, it's in a handful of places in the stdlib: asyncio, functools, importlib. The earliest it appeared was in 3.7.0a4. It's in more places in the test suite, which I think is a closer parallel to this maintainer script in Tools/. The typing module itself is in the stdlib, so I don't see any obstacle to using it more widely. I imagine the main reason it doesn't appear more widely already is simply that it's new, and most of the stdlib is quite stable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:54:31 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 17:54:31 +0000 Subject: [issue37841] Python store app launcher has dependency on msvcp140.dll In-Reply-To: <1565711367.34.0.212877315326.issue37841@roundup.psfhosted.org> Message-ID: <1565718871.52.0.99734213946.issue37841@roundup.psfhosted.org> miss-islington added the comment: New changeset 853eecc7692503fec8240fd9a74d9f88e0392630 by Miss Islington (bot) in branch '3.8': bpo-37841: Remove python_uwp dependency on msvcp140.dll (GH-15253) https://github.com/python/cpython/commit/853eecc7692503fec8240fd9a74d9f88e0392630 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:55:52 2019 From: report at bugs.python.org (hai shi) Date: Tue, 13 Aug 2019 17:55:52 +0000 Subject: [issue37583] Got a 113 error when running the test_socket In-Reply-To: <1563006871.17.0.626459715079.issue37583@roundup.psfhosted.org> Message-ID: <1565718952.59.0.515479727998.issue37583@roundup.psfhosted.org> Change by hai shi : ---------- pull_requests: +14978 pull_request: https://github.com/python/cpython/pull/15259 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 13:57:17 2019 From: report at bugs.python.org (Netzeband) Date: Tue, 13 Aug 2019 17:57:17 +0000 Subject: [issue37838] typing.get_type_hints not working with forward-declaration and decorated functions In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org> Message-ID: <1565719037.78.0.871147014547.issue37838@roundup.psfhosted.org> Netzeband added the comment: Thanks for your feedback. I can create a pull-request. However, I did it never before for the Python-Lib, so I first have to setup the correct environment for that and ensure, that I can run all test-cases. Since I'm on vacation soon, it could take several weeks. If someone wants to solve the issue earlier, please don't hesitate. I will write it in this issue ticket, as soon as I finished the PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 14:06:09 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Aug 2019 18:06:09 +0000 Subject: [issue37813] PEP 7 line-breaking with binary operations contradicts Knuth's rule In-Reply-To: <1565473572.7.0.81062665759.issue37813@roundup.psfhosted.org> Message-ID: <1565719569.97.0.067600524826.issue37813@roundup.psfhosted.org> Guido van Rossum added the comment: PEP 8 intentionally allows users to choose whether to put the operator at the start or end of the line (as long as they're consistent within a file or project). This is to avoid a barrage of "style fixes" that are just noise. But PEP 7 is only for CPython's own C code style, and here I don't want things to change. When it comes to readability of our code surely there are bigger fish to fry. So I'm closing this as won't fix. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 14:11:53 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 18:11:53 +0000 Subject: [issue37583] Got a 113 error when running the test_socket In-Reply-To: <1563006871.17.0.626459715079.issue37583@roundup.psfhosted.org> Message-ID: <1565719913.51.0.827171248798.issue37583@roundup.psfhosted.org> miss-islington added the comment: New changeset ee989512528d178d6f088916aba3e67ea9487ceb by Miss Islington (bot) in branch '3.8': bpo-37583: Add err 113 to support.get_socket_conn_refused_errs() (GH-14729) https://github.com/python/cpython/commit/ee989512528d178d6f088916aba3e67ea9487ceb ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 14:12:50 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Aug 2019 18:12:50 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565719970.94.0.157415269918.issue37834@roundup.psfhosted.org> Steve Dower added the comment: > If we support reading junctions, this should be using the substitute name (with \??\ replaced by \\?\) instead of the print name. GetFinalPathName() does this conversion for us, any reason not to use that? (GetFullPathName() doesn't seem to recognize the \??\ prefix and will prepend the current drive) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 14:21:40 2019 From: report at bugs.python.org (Christian Biesinger) Date: Tue, 13 Aug 2019 18:21:40 +0000 Subject: [issue37844] PyRun_SimpleFile should provide a version that does not need a FILE* Message-ID: <1565720500.55.0.0348058431334.issue37844@roundup.psfhosted.org> New submission from Christian Biesinger : Because FILE* requires that the runtime library matches between Python and a program using it, it is very hard to use this correctly on Windows. It would be nice if Python provided either: - A function to open a FILE* given a filename, suitable for passing to the various PyRun_* functions, or - Versions of the functions that take a filename and internally open the file (ref: https://docs.python.org/3.9/c-api/veryhigh.html, which talks about this but provides no useful guidance: "One particular issue which needs to be handled carefully is that the FILE structure for different C libraries can be different and incompatible. Under Windows (at least), it is possible for dynamically linked extensions to actually use different libraries, so care should be taken that FILE* parameters are only passed to these functions if it is certain that they were created by the same library that the Python runtime is using." ) ---------- components: Windows messages: 349598 nosy: cbiesinger, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: PyRun_SimpleFile should provide a version that does not need a FILE* type: crash versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 14:22:50 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Aug 2019 18:22:50 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565720570.3.0.0134399758706.issue37760@roundup.psfhosted.org> Serhiy Storchaka added the comment: What is the minimal Python version for developing CPython? The system Python 3 on current Ubuntu LTS (18.04) is 3.6, so I think it should not be larger. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 14:33:24 2019 From: report at bugs.python.org (David K.) Date: Tue, 13 Aug 2019 18:33:24 +0000 Subject: [issue37845] SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start Message-ID: <1565721204.27.0.66064229859.issue37845@roundup.psfhosted.org> New submission from David K. : Unable to establish SSL connections using company's private certificates where their SANs (Subject Alternative Names) contain at least one DNS Name that starts with white spaces. Attempting to establish SSL connection would result in Exception: SSLCertVerificationError("partial wildcards in leftmost label are not supported: ' *.x.y.com'.") This situation made us co-depended on SecOps in a big company where ultimately all other none-python apps weren't effected by that change they made and thus couldn't or wouldn't fix the problem on their side for us. (We were at their mercy!) I originally encountered this bug @ Python 3.7 and fixed it manually on my own local Python environment. As the bug seems to be still unfixed to date, I publish this issue. A small and simple fix will follow shortly on github. ---------- assignee: christian.heimes components: SSL messages: 349600 nosy: DK26, christian.heimes priority: normal severity: normal status: open title: SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start type: security versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 14:35:56 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Aug 2019 18:35:56 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565721356.66.0.695395031566.issue37834@roundup.psfhosted.org> Steve Dower added the comment: Latest PR update uses GetFinalPathName to resolve SubstituteName, returning it unmodified on failure (e.g. symlink where the target file no longer exists). Replacing "\??\" with "\\?\" in place is trivial though, as we start with a mutable buffer. I'm just not clear that it's as simple as that, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 14:48:18 2019 From: report at bugs.python.org (Greg Price) Date: Tue, 13 Aug 2019 18:48:18 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565722098.67.0.0932963837797.issue37760@roundup.psfhosted.org> Greg Price added the comment: > What is the minimal Python version for developing CPython? The system Python 3 on current Ubuntu LTS (18.04) is 3.6, so I think it should not be larger. Ah, I think my previous message had an ambiguous parse: the earliest that *uses* of the typing module appeared in the stdlib was 3.7. The typing module has been around longer than that. I just checked and `python3.6 Tools/unicode/makeunicodedata.py` works fine, both at master and with GH-15248. I think it would be OK for doing development on CPython to require the latest minor version (i.e. 3.7) -- after all, if you're doing development, you're already building it, so you can always get a newer version than your system provides if needed. But happily the question is moot here, so I guess the place to discuss that further would be a new thread. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 14:55:37 2019 From: report at bugs.python.org (David K.) Date: Tue, 13 Aug 2019 18:55:37 +0000 Subject: [issue37845] SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start In-Reply-To: <1565721204.27.0.66064229859.issue37845@roundup.psfhosted.org> Message-ID: <1565722537.51.0.141636320727.issue37845@roundup.psfhosted.org> Change by David K. : ---------- keywords: +patch pull_requests: +14979 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15260 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 14:56:02 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Aug 2019 18:56:02 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565722562.63.0.0449912863655.issue37760@roundup.psfhosted.org> Serhiy Storchaka added the comment: > I just checked and `python3.6 Tools/unicode/makeunicodedata.py` works fine, both at master and with GH-15248. This is good. But the title mentioned dataclasses, and they are 3.7+. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 14:57:33 2019 From: report at bugs.python.org (Bennet Fauber) Date: Tue, 13 Aug 2019 18:57:33 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565722653.19.0.254067724667.issue21131@roundup.psfhosted.org> Bennet Fauber added the comment: One additional note on this. Thanks to a colleague at USC who pointed out that this bug does not seem to get exercised if one does not include `--enable-shared` at configuration. I confirmed this using the distributed Python-3.7.4.tgz file and `configure --prefix=/path/to/install`. The `make test` then runs to completion with no errors. Running `make distclean`, then rerunning with `configure --prefix=/path/to/install --enable-shared` will then exercise the bug, and the faulthandler test fails with a segfault. Applying the patch file attached to this report and rebuilding leads to `make test` passing all tests, also. If someone was trying to reproduce and did not configure shared libraries, then that would have failed to reproduce. ---------- nosy: +justbennet _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 15:03:12 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 13 Aug 2019 19:03:12 +0000 Subject: [issue37830] continue and break in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565722992.66.0.635990572021.issue37830@roundup.psfhosted.org> Serhiy Storchaka added the comment: There may be a solution that does not require a significant change to the code generator, but small changes in many places with keeping the general structure. But it is a difficult task, so it takes some time. Don't worry, I'm working on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 15:05:16 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 19:05:16 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented In-Reply-To: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> Message-ID: <1565723116.98.0.382708896347.issue37814@roundup.psfhosted.org> miss-islington added the comment: New changeset 8a784af750fa82c8355903309e5089eb2b60c16b by Miss Islington (bot) (Josh Holland) in branch 'master': bpo-37814: Document the empty tuple type annotation syntax (GH-15208) https://github.com/python/cpython/commit/8a784af750fa82c8355903309e5089eb2b60c16b ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 15:05:56 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 19:05:56 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented In-Reply-To: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> Message-ID: <1565723156.27.0.725028436777.issue37814@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14980 pull_request: https://github.com/python/cpython/pull/15261 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 15:12:58 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 19:12:58 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented In-Reply-To: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> Message-ID: <1565723578.86.0.193735023792.issue37814@roundup.psfhosted.org> miss-islington added the comment: New changeset 6ad902a08814909b4d52c4000d5a10ce58516dac by Miss Islington (bot) in branch '3.8': bpo-37814: Document the empty tuple type annotation syntax (GH-15208) https://github.com/python/cpython/commit/6ad902a08814909b4d52c4000d5a10ce58516dac ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 15:15:08 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Tue, 13 Aug 2019 19:15:08 +0000 Subject: [issue35669] tar symlink In-Reply-To: <1546765691.35.0.523415727187.issue35669@roundup.psfhosted.org> Message-ID: <1565723708.46.0.00625765937273.issue35669@roundup.psfhosted.org> Ashwin Ramaswami added the comment: I believe the SafeTarFile class proposed in issue21109 fixes this. ---------- nosy: +epicfaace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 15:16:02 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 13 Aug 2019 19:16:02 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented In-Reply-To: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> Message-ID: <1565723762.36.0.585173253483.issue37814@roundup.psfhosted.org> Guido van Rossum added the comment: Thanks Josh! The automated backport to 3.7 didn't work, that's okay, so I'll close this now. (Though if you want to experiment with the cherry-picker tool go ahead.) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 15:20:24 2019 From: report at bugs.python.org (Josh Holland) Date: Tue, 13 Aug 2019 19:20:24 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented In-Reply-To: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> Message-ID: <1565724024.17.0.943408095574.issue37814@roundup.psfhosted.org> Change by Josh Holland : ---------- pull_requests: +14981 pull_request: https://github.com/python/cpython/pull/15262 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 15:23:07 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Tue, 13 Aug 2019 19:23:07 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565724187.19.0.751812156458.issue29535@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- nosy: +epicfaace versions: +Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 15:26:19 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 19:26:19 +0000 Subject: [issue37814] typing module: empty tuple syntax is undocumented In-Reply-To: <1565483794.67.0.80364614628.issue37814@roundup.psfhosted.org> Message-ID: <1565724379.84.0.977340057158.issue37814@roundup.psfhosted.org> miss-islington added the comment: New changeset 37fd9f73e2fa439554977cfba427bf94c1fedb6b by Miss Islington (bot) (Josh Holland) in branch '3.7': [3.7] bpo-37814: Document the empty tuple type annotation syntax (GH-15208) (GH-15262) https://github.com/python/cpython/commit/37fd9f73e2fa439554977cfba427bf94c1fedb6b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 15:46:07 2019 From: report at bugs.python.org (Eryk Sun) Date: Tue, 13 Aug 2019 19:46:07 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565725567.01.0.694928000585.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > I feel like that's more work than is worth us doing for something that > will be relatively rarely used, will live in the stdlib, and is > obviously something that will become outdated as Microsoft adds new > reparse points. Junctions (NT 5) and symlinks (NT 6) are stable. So if os.read_reparse_point only returns the unparsed bytes, maybe add os.read_junction as well. I know other projects overload this on POSIX readlink. They're both name-surrogate reparse points, but they have different constraints and behavior. The I/O manager tries to make a junction behave something like a hard link to a directory, with the addition of being able to link across local volumes. This is in turn relates to how it evaluates relative symbolic links. For example, if "C:/Junction" and "C:/Symlink" both target r"\\?\C:\Temp1\Temp2", and there's a relative symlink "C:/Temp1/Temp2/foo_link" that targets r"..\foo", then "C:/Junction/foo_link" references "C:/foo" but "C:/Symlink/foo_link" references "C:/Temp1/foo". Another difference is with remote filesystems. SMB special cases symlinks to have the server send the reparse request over the wire to be evaluated on the client side. (Refer to [MS-SMB2] 2.2.2.1 Symbolic Link Error Response, and the subsequent section about client-side handling of this error.) So an absolute symlink on the server that targets r"\\?\C:\Windows" actually references the client's "C:/Windows" directory, whereas the same junction target would reference the server's "C:/Windows" directory. The symlink evaluation will succeed only if the client's R2L (remote to local) policy allows it. Symlinks can also target remote devices, depending on the L2R and R2R policy settings. Junctions are restricted to local devices. > In theory, we can't follow any reparse point that isn't documented as > being followable and provides the target name is a stable, documented > manner. To follow a reparse point, we're just calling CreateFileW the normal way, without FILE_FLAG_OPEN_REPARSE_POINT. The Windows API also does this (usually via NtOpenFile, but this has a similar FILE_OPEN_REPARSE_POINT option) for tags it doesn't handle. That's why MoveFileExW (os.rename and os.replace) fails on one of these app-exec links. In some cases, it adds a third open attempt if the reparse point isn't handled. This is important for DeleteFileW (os.remove) and RemoveDirectoryW (os.rmdir) because we should be able to delete a bad reparse point. > The appexec links don't do this (I just looked at the returned > buffer), so we really should just not follow them. They exist solely > so that CreateProcess internally returns a unique error code that can > be handled without impacting regular process start, which means we > *don't* want to follow them. I know, so a regular stat() will fail. I think for an honest result, stat() should fail for a reparse point that can't be handled. Scripts can use stat(path, follow_nonlinks=False) or stat(path, follow_reparse_points=False), or however this eventually gets parameterized to force opening all reparse points. > Now, directory junctions are far more interesting. My gut feel is that > we should treat them the same as symlinks (with respect to stat vs. > lstat) for consistency Junctions are their own thing. They're mount points that behave like Unix volume mounts (in Windows, target the root directory of a volume device named by its "Volume{...}" name) or Unix bind mounts (in Windows, target arbitrary directories on any local volume; in Linux it's a mount created with --bind or FUSE bindfs). Bind-like junctions are also similar to DOS subst drives (e.g. "W:" -> "C:/Windows") and UNC shares. These are all mount points of one sort or another. OTOH, the base device names such as "//?/C:" and "//?/Volume{...}", without a specified root directory, are aliases (object symlinks) for an NT device such as r"\Device\HarddiskVolume2". These paths open the volume itself, not the mounted filesystem, so they're not like Unix mount points. They're like Unix '/dev/sda1' device paths, except in Unix, devices don't have their own namespaces, so it would be nonsense to open "/dev/sda1/". RemoveDirectoryW for a volume mount is special cased to call DeleteVolumeMountPointW, which notifies the mount-point manager. It won't do this for a junction that targets the same volume root directory via the DOS drive-letter name -- or any other device alias for that matter (e.g. Windows 10 creates "\\?\BootPartition" as an alternative named for the system "C:" drive). So bind-like mounts are different from volume mounts, but both are different from symlinks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 15:54:06 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 Aug 2019 19:54:06 +0000 Subject: [issue37689] Add Path.is_relative_to() In-Reply-To: <1564156564.69.0.23140154802.issue37689@roundup.psfhosted.org> Message-ID: <1565726046.16.0.367038751403.issue37689@roundup.psfhosted.org> Antoine Pitrou added the comment: New changeset 82642a052dc46b2180679518bc8d87e1a28a88b5 by Antoine Pitrou (Hai Shi) in branch 'master': bpo-37689: add Path.is_relative_to() method (GH-14982) https://github.com/python/cpython/commit/82642a052dc46b2180679518bc8d87e1a28a88b5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 15:54:35 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 13 Aug 2019 19:54:35 +0000 Subject: [issue37689] Add Path.is_relative_to() In-Reply-To: <1564156564.69.0.23140154802.issue37689@roundup.psfhosted.org> Message-ID: <1565726075.86.0.466386595121.issue37689@roundup.psfhosted.org> Change by Antoine Pitrou : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 16:02:05 2019 From: report at bugs.python.org (Greg Price) Date: Tue, 13 Aug 2019 20:02:05 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565726525.77.0.68794317836.issue37760@roundup.psfhosted.org> Greg Price added the comment: > This is good. But the title mentioned dataclasses, and they are 3.7+. Ahh, sorry, I think now I understand you. :-) Indeed, when I switch to the branch with that change (https://github.com/gnprice/cpython/commit/2b4aec4dd -- it comes after the patch that's GH-15248, so I haven't yet sent it as a PR), then `python3.6 Tools/unicode/makeunicodedata.py` no longer works. I think this is fine. Most of all that's because this always works: ./python Tools/unicode/makeunicodedata.py Anyone who's going to be running that script will want to build a `./python` right afterward, in order to at least run the tests. So it doesn't seem like much trouble to do the build first and then run the script (and then a quick rebuild for the handful of changed files), if indeed the person doesn't already have a `./python` lying around. In fact `./python` is exactly what I used most of the time to run this script when I was developing these changes, simply because it seemed like the natural thing to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 16:20:57 2019 From: report at bugs.python.org (Greg Price) Date: Tue, 13 Aug 2019 20:20:57 +0000 Subject: [issue32771] merge the underlying data stores of unicodedata and the str type In-Reply-To: <1517797199.65.0.467229070634.issue32771@psf.upfronthosting.co.za> Message-ID: <1565727657.32.0.799965039323.issue32771@roundup.psfhosted.org> Greg Price added the comment: > Loading it dynamically reduces the memory footprint. Ah, this is a good question to ask! First, FWIW on my Debian buster desktop I get a smaller figure for `import unicodedata`: only 64 kiB. $ python Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") VmRSS: 9888 kB >>> import unicodedata >>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") VmRSS: 9952 kB But whether 64 kiB or 160 kiB, it's much smaller than the 1.1 MiB of the whole module. Which makes sense -- there's no need to bring the whole thing in memory when we only import it, or generally to bring into memory the parts we aren't using. I wouldn't expect that to change materially if the tables and algorithms were built in. Here's another experiment: suppose we load everything that ast.c needs in order to handle non-ASCII identifiers. $ python Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") VmRSS: 9800 kB >>> l? = 3 >>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") VmRSS: 9864 kB So that also comes to 64 kiB. We wouldn't want to add 64 kiB to our memory use for no reason; but I think 64 or 160 kiB is well within the range that's an acceptable cost if it gets us a significant simplification or improvement to core functionality, like Unicode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 16:22:23 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 13 Aug 2019 20:22:23 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565727743.15.0.282276381857.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: Thank you @paul.moore ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 16:22:31 2019 From: report at bugs.python.org (Greg Price) Date: Tue, 13 Aug 2019 20:22:31 +0000 Subject: [issue32771] merge the underlying data stores of unicodedata and the str type In-Reply-To: <1517797199.65.0.467229070634.issue32771@psf.upfronthosting.co.za> Message-ID: <1565727751.28.0.548263776384.issue32771@roundup.psfhosted.org> Greg Price added the comment: Speaking of improving functionality: > Having unicodedata readily accessible to the str type would also permit higher a fidelity unicode implementation. For example, implementing language-tailored str.lower() requires having canonical combining class of a character available. This data lives only in unicodedata currently. Benjamin, can you say more about the behavior you have in mind here? I don't entirely follow. (Is or should there be an issue for it?) ---------- versions: +Python 3.9 -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 16:23:46 2019 From: report at bugs.python.org (Eryk Sun) Date: Tue, 13 Aug 2019 20:23:46 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565727826.4.0.740330716905.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > Replacing "\??\" with "\\?\" in place is trivial though, as we start > with a mutable buffer. I'm just not clear that it's as simple as that, > though. If the path starts with "\\??\\" we can just change the first question mark to a backslash. For a symlink, fail at this step if Flags includes SYMLINK_FLAG_RELATIVE, which would be inconsistent data. "\\??\\" is the NT prefix for the caller's local (logon session) device directory. This implicitly shadows the global device directory, "\\Global??". We don't use NT's real "\\Device" directory in Windows, but it's available as "//?/GlobalRoot/Device" or "//?/Global/GlobalRoot/Device". "\\??\\" shouldn't be used directly in Windows programming, since GetFullPathNameW (often implicitly called) doesn't recognize it, but some API functions will pass it along, even though they should really fail the call. It will work until it doesn't, and by then we could have a right mess. If a path starts with exactly "\\\\?\\" (backslash only), Windows simply copies it verbatim, except for changing the prefix to "\\??\\". Other Windows device prefixes where the domain is "." or "?" can use any mix of forward slash and backslash because they get normalized first (e.g. "//?\\" -> "\\\\?\\"). Only an initial "\\\\?\\" bypasses the normalization step. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 16:42:48 2019 From: report at bugs.python.org (Armin Rigo) Date: Tue, 13 Aug 2019 20:42:48 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565728968.66.0.774787180724.issue29535@roundup.psfhosted.org> Change by Armin Rigo : ---------- nosy: -arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 17:04:40 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Aug 2019 21:04:40 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565730280.06.0.125282890423.issue37834@roundup.psfhosted.org> Steve Dower added the comment: I think we'll want issue9949 merged as well, so that ntpath.realpath() does its job. Certainly the tests would benefit from it. Until then, I think it makes sense for os.readlink() to handle the prefix and _getfinalpathname() call, but leave nt.readlink() as returning the raw value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 17:27:18 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 21:27:18 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565731638.69.0.818682999151.issue25172@roundup.psfhosted.org> miss-islington added the comment: New changeset 7f7f74734acd729d1f82b7cf672e064c9525fced by Miss Islington (bot) in branch '3.8': bpo-25172: Raise appropriate ImportError msg when crypt module used on Windows (GH-15149) https://github.com/python/cpython/commit/7f7f74734acd729d1f82b7cf672e064c9525fced ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 17:27:37 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Aug 2019 21:27:37 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565731657.07.0.660089138875.issue25172@roundup.psfhosted.org> Steve Dower added the comment: New changeset 243a73deee4ac61fe06602b7ed56b6df01e19f27 by Steve Dower (shireenrao) in branch 'master': bpo-25172: Add test for crypt ImportError on Windows (GH-15252) https://github.com/python/cpython/commit/243a73deee4ac61fe06602b7ed56b6df01e19f27 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 17:28:02 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 21:28:02 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565731682.44.0.815036922156.issue25172@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14982 pull_request: https://github.com/python/cpython/pull/15263 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 17:30:21 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 13 Aug 2019 21:30:21 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565731821.3.0.59456060652.issue25172@roundup.psfhosted.org> Steve Dower added the comment: Thanks for the patches, Srinivas! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 17:39:40 2019 From: report at bugs.python.org (Eryk Sun) Date: Tue, 13 Aug 2019 21:39:40 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565732380.06.0.47390668943.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > Until then, I think it makes sense for os.readlink() to handle the > prefix and _getfinalpathname() call, but leave nt.readlink() as > returning the raw value. os.readlink() shouldn't resolve the final path or realpath(). It should simply return the link substitute path, which starts with "\\\\?\\". I'm wary of trying to return it without the prefix. We would need a function that's shared with the proposed implementation of realpath() to determine whether the given path (not the final path) is safe to return as a normal DOS or UNC path. --- BTW, I looked into how CreateFileW is supporting "\\??\\". It turns out at some point they changed RtlpDosPathNameToRelativeNtPathName to look for both "\\\\?\\" and "\\??\\" when determining whether to skip normalizing the path. I think that's a bad idea since the Windows API doesn't consistently support the NT prefix. ReactOS is supposed to target NT 5.2 (Server 2003), and it doesn't allow the NT prefix here. Refer to its implementation of RtlpDosPathNameToRelativeNtPathName_Ustr [1]. It only looks for RtlpWin32NtRootSlash ("\\\\?\\"), not RtlpDosDevicesPrefix ("\\??\\"). So I suppose Windows changed this some time between Vista and Windows 10. [1] https://github.com/reactos/reactos/blob/d93e516747e3220ba182f77824e8b1a8b548edae/sdk/lib/rtl/path.c#L1034 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 17:52:23 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 13 Aug 2019 21:52:23 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565733143.81.0.437737698946.issue25172@roundup.psfhosted.org> miss-islington added the comment: New changeset e7ec9e04c82be72aef621fdfba03f41cbd8599aa by Miss Islington (bot) in branch '3.8': bpo-25172: Add test for crypt ImportError on Windows (GH-15252) https://github.com/python/cpython/commit/e7ec9e04c82be72aef621fdfba03f41cbd8599aa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 18:18:52 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 13 Aug 2019 22:18:52 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> Message-ID: <1565734732.86.0.0347793183664.issue25172@roundup.psfhosted.org> Srinivas Nyayapati added the comment: Thank you Steve for accepting my pull requests. I was surprised to see the methods in the class and its decorators getting evaluated and causing the failures initially, but I then realized that the code is parsed before execution and that's when I was seeing the failure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 18:35:07 2019 From: report at bugs.python.org (Bennet Fauber) Date: Tue, 13 Aug 2019 22:35:07 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565735707.48.0.818715714053.issue21131@roundup.psfhosted.org> Bennet Fauber added the comment: Perhaps I should add, that we are able to reproduce this behavior on this hardware Dell R640 Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz Dell R740 Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz Dell R440 Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz Dell C6420 Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz but not on other chips, such as a recent i5, Haswell family, and older. That may also make a difference if someone tries to reproduce this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 20:15:53 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 14 Aug 2019 00:15:53 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565741753.38.0.821277015771.issue37834@roundup.psfhosted.org> Steve Dower added the comment: > I'm wary of trying to return it without the prefix. Me too, but suddenly adding "\\?\" to the paths breaks a lot of assumptions. > We would need a function that's shared with the proposed implementation of realpath() to determine whether the given path (not the final path) is safe to return as a normal DOS or UNC path. My idea was to GetFinalPathName(path[4:])[4:] and if that fails, don't strip the prefix. Which is obviously not be perfect, but since we're not going to add a check for the LongPathsEnabled flag (let alone any of the other edge cases), we can't easily figure out whether it's safe to return manually. I really want a fix for this in 3.8, or else os.stat(sys.executable) may fail, but I don't think changing the result of readlink() is okay at this stage. Maybe I'll leave that out for now and just take the st_reparse_tag and stat() changes? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 20:42:30 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 14 Aug 2019 00:42:30 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565743350.74.0.228160119868.issue29535@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- keywords: +patch pull_requests: +14983 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15264 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 21:11:04 2019 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 14 Aug 2019 01:11:04 +0000 Subject: [issue37256] urllib.request.Request documentation erroneously refers to the "final two" In-Reply-To: <1560366755.97.0.221740241329.issue37256@roundup.psfhosted.org> Message-ID: <1565745064.14.0.518396424322.issue37256@roundup.psfhosted.org> Senthil Kumaran added the comment: New changeset 38c7199beb30ae9a5005c0f0d9df9fae0da3680a by Senthil Kumaran (Ngalim Siregar) in branch 'master': bpo-37256: Wording in Request class docs (#14792) https://github.com/python/cpython/commit/38c7199beb30ae9a5005c0f0d9df9fae0da3680a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 21:20:04 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 14 Aug 2019 01:20:04 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565745604.87.0.620904229627.issue37831@roundup.psfhosted.org> Raymond Hettinger added the comment: Essentially we've got two competing desires: * Given that & | and ^ are closed under bools, it would be nice for ~ to be closed as well. NOT isn't a reasonable alternative because of its operator precedence. * Given that bool is a subclass of int, its operations should give results equivalent to what you would get for ints. When reopening this, my thought was that the first desire should win based on practicality- beats-purity. In the context of bools, the current ~ operator violates user expectations and there isn't a reasonable alternative that has the correct precedence. But in the face of opposition to the idea, am willing to just let it die. In the scheme of things, it isn't important. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 22:24:36 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 14 Aug 2019 02:24:36 +0000 Subject: [issue32771] merge the underlying data stores of unicodedata and the str type In-Reply-To: <1517797199.65.0.467229070634.issue32771@psf.upfronthosting.co.za> Message-ID: <1565749476.91.0.971271843163.issue32771@roundup.psfhosted.org> Benjamin Peterson added the comment: The goal is to implement the locale-specific case mappings of https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt and ?3.13 of the Unicode 12 standard in str.lower/upper/casefold. To do this, you need access to certain character properties available in unicodedata but not the builtin database. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 22:27:14 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 14 Aug 2019 02:27:14 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565749634.86.0.851538324719.issue37760@roundup.psfhosted.org> Benjamin Peterson added the comment: >From my perspective, the main problem with using type annotations is that there's nothing checking them in CI. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 22:28:45 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 14 Aug 2019 02:28:45 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565749725.22.0.510755438767.issue37760@roundup.psfhosted.org> Benjamin Peterson added the comment: New changeset c03e698c344dfc557555b6b07a3ee2702e45f6ee by Benjamin Peterson (Greg Price) in branch 'master': bpo-37760: Factor out standard range-expanding logic in makeunicodedata. (GH-15248) https://github.com/python/cpython/commit/c03e698c344dfc557555b6b07a3ee2702e45f6ee ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 22:39:33 2019 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 14 Aug 2019 02:39:33 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1565750373.35.0.56611202001.issue37757@roundup.psfhosted.org> Nick Coghlan added the comment: The outcome of the python-dev discussion was that we agreed to switch to raising a plain SyntaxError, as that's what we do everywhere else that this kind of problem comes up (e.g. conflicts between global and nonlocal declarations, or between those and parameter declarations, as well as the various other cases of "that statement/expression is fine in isolation, but you can't use it *here*"). Both PRs have been updated accordingly, and the PEP PR has been merged. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 22:44:09 2019 From: report at bugs.python.org (Windson Yang) Date: Wed, 14 Aug 2019 02:44:09 +0000 Subject: [issue37846] declare that Text I/O use buffer inside Message-ID: <1565750649.11.0.831019575323.issue37846@roundup.psfhosted.org> New submission from Windson Yang : At the beginning of https://docs.python.org/3.7/library/io.html#io.RawIOBase, we declared that > Binary I/O (also called buffered I/O) and > Raw I/O (also called unbuffered I/O) But we didn't mention if Text I/O use buffer or not which led to confusion. Even though we talked about it later in https://docs.python.org/3.7/library/io.html#class-hierarchy > The TextIOBase ABC, another subclass of IOBase, deals with streams whose bytes represent text, and handles encoding and decoding to and from strings. TextIOWrapper, which extends it, is a buffered text interface to a buffered raw stream (BufferedIOBase). Finally, StringIO is an in-memory stream for text. IMO, it will be better to declare 'Reads and writes are internally buffered in order to speed things up' at the very beginning in > Text I/O > Text I/O expects and produces str objects... or maybe > class io.TextIOBase > Base class for text streams. This class provides a character and line based interface to stream I/O. It inherits IOBase. There is no public constructor. ---------- assignee: docs at python components: Documentation messages: 349633 nosy: Windson Yang, docs at python priority: normal severity: normal status: open title: declare that Text I/O use buffer inside type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 23:02:56 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 14 Aug 2019 03:02:56 +0000 Subject: [issue37821] IDLE shell uses wrong namespace for completions In-Reply-To: <1565522228.88.0.811193115322.issue37821@roundup.psfhosted.org> Message-ID: <1565751776.03.0.22622557007.issue37821@roundup.psfhosted.org> Terry J. Reedy added the comment: The current behavior is the quick and easy/dirty solution that we have, not what we especially want. #27609 has multiple issues and ideas for completion improvements. I made testing and improving the code priorities before worrying about most of the proposed changes. Here is where we got confused a bit. The title refers to shell completions. The opening post starts with shell completions and then moves to intended behavior for editor completions and its dependence on the presence of a shell. I disagreed with the latter and responded, not thinking much about shell completions. Lets stick to shell completions, at least initially (and change the title if we include editor completions). Tal: "Perhaps we should differentiate between completions in the shell vs. when editing a file." I agree that we can consider adjusting the list according to the setting. It is easy enough. Open_completions, executed in the idle process, can detect whether the associated text is the shell or an editor and pass a (new) flag to fetch_completions, which will pass it to the fetch_completions executed in the run process. Tal: "In the shell, having completions for things not actually available is weird". That I can see and agree to. While the editor allows after-completion revisions anywhere in the file before running, the user cannot revise Shell history and insert an executed import before executing the current statement. A doc statement like "Name and attribute completion in the shell is restricted to names and objects available after previous shell statements." seems clear enough to anyone who reads it. As near as I can tell, both before and after the #21261 patch, name (tab) completion *is* restricted to valid names. But attribute completion will complete for modules such as socket import by run.py even when not in the main namespace. Python in masOS Terminal (bash, I believe) does attribute completion (.), but only for user visible names, not, for instance, for reprlib. The proposal is to restrict IDLE's Shell's attribute completion similarly. Tal: "I really dislike the arbitrary availability of only certain modules for completion." It is not completely arbitrary. We could complete stdlib names from a pre-generated list. But that would add perhaps 400 names to the name completion list. But we can only complete attributes (which I, at least, use much more) for modules in sys.modules. A possible improvement mentioned more than once is on-demand import, at least of stdlib modules. If any are shown to be a problem, we could make a blacklist. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 23:22:20 2019 From: report at bugs.python.org (Artem Khramov) Date: Wed, 14 Aug 2019 03:22:20 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) In-Reply-To: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> Message-ID: <1565752940.27.0.0622699531798.issue37811@roundup.psfhosted.org> Change by Artem Khramov : ---------- components: +FreeBSD, IO, Library (Lib), macOS nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 23:30:11 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 14 Aug 2019 03:30:11 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565753411.21.0.0292295399367.issue29535@roundup.psfhosted.org> Ashwin Ramaswami added the comment: I've added a PR which should fix this. Do you think the documentation should also be updated to change "By default, the :meth:`__hash__` values of str, bytes and datetime objects are "salted" with an unpredictable random value." to "By default, the :meth:`__hash__` values of str, bytes, datetime.date, datetime.time and datetime.datetime objects are "salted" with an unpredictable random value."? Technically, there are other objects in datetime such as datetime.relativedelta whose hash values are _not_ non-deterministic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 23:33:35 2019 From: report at bugs.python.org (Isuru Fernando) Date: Wed, 14 Aug 2019 03:33:35 +0000 Subject: [issue32423] The Windows SDK version 10.0.15063.0 was not found In-Reply-To: <1514094015.43.0.213398074469.issue32423@psf.upfronthosting.co.za> Message-ID: <1565753615.0.0.165665668368.issue32423@roundup.psfhosted.org> Isuru Fernando added the comment: Fixed in https://github.com/python/cpython/pull/12445 ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 23:37:15 2019 From: report at bugs.python.org (Edwin Pratt) Date: Wed, 14 Aug 2019 03:37:15 +0000 Subject: [issue37847] The IDLE does not show previous code suggestions if I tap on the up arrow Message-ID: <1565753835.82.0.953640803878.issue37847@roundup.psfhosted.org> New submission from Edwin Pratt : If I am typing some Python code in the IDLE, for example a function: def sayHi(name): print('Hello ', name) and I execute the function: sayHi('Ed') I can not edit the function or execute a previous line of code again if I tap the up arrow on my keyboard. It seemed to work in the previous versions of Python. In order to execute a previous line of code I have to either copy it, or type it in again. ---------- assignee: terry.reedy components: IDLE messages: 349638 nosy: Edwin Pratt, terry.reedy priority: normal severity: normal status: open title: The IDLE does not show previous code suggestions if I tap on the up arrow type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 13 23:46:15 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 14 Aug 2019 03:46:15 +0000 Subject: [issue35214] Get the test suite passing with clang Memory Sanitizer enabled In-Reply-To: <1542007595.0.0.788709270274.issue35214@psf.upfronthosting.co.za> Message-ID: <1565754375.84.0.316686550042.issue35214@roundup.psfhosted.org> Ashwin Ramaswami added the comment: Can this be closed now? ---------- nosy: +epicfaace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 00:01:33 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 14 Aug 2019 04:01:33 +0000 Subject: [issue33661] urllib may leak sensitive HTTP headers to a third-party web site In-Reply-To: <1527430806.55.0.682650639539.issue33661@psf.upfronthosting.co.za> Message-ID: <1565755293.28.0.636527825443.issue33661@roundup.psfhosted.org> Ashwin Ramaswami added the comment: Martin, are you okay with doing this? It seems like this issue has been the topic of a few CVEs (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20060, https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-18074, https://curl.haxx.se/docs/CVE-2018-1000007.html) as well. ---------- nosy: +epicfaace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 00:52:22 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 14 Aug 2019 04:52:22 +0000 Subject: [issue17305] IDNA2008 encoding is missing In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za> Message-ID: <1565758342.83.0.26554637956.issue17305@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- nosy: +epicfaace versions: +Python 3.9 -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 00:55:24 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 14 Aug 2019 04:55:24 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565758524.49.0.84179369575.issue37760@roundup.psfhosted.org> Greg Price added the comment: > From my perspective, the main problem with using type annotations is that there's nothing checking them in CI. Yeah, fair concern. In fact I think I'm on video (from PyCon 2018) warning everyone not to do that in their codebases, because what you really don't want is a bunch of annotations that have gradually accumulated falsehoods as the code has changed around them. Still, I think from "some annotations + no checking" the good equilibrium to land in "some annotations + checking", not "no annotations + no checking". (I do mean "some" -- I don't predict we'll ever go sweep all over adding them.) And I think the highest-probability way to get there is to let them continue to accumulate where people occasionally add them in new/revised code... because that holds a door open for someone to step up to start checking them, and then to do the work to make that part of CI. (That someone might even be me! But I can think of plenty of other likely folks to do it.) If we accumulated quite a lot of them and nobody had yet stepped up to make checking happen, I'd worry. But with the smattering we currently have, I think that point is far off. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 00:55:34 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 14 Aug 2019 04:55:34 +0000 Subject: [issue17305] IDNA2008 encoding is missing In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za> Message-ID: <1565758534.93.0.00862285646916.issue17305@roundup.psfhosted.org> Ashwin Ramaswami added the comment: Why would chrome still be using IDNA 2003 to link http://stra?e.de to http://strasse.de? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 00:59:58 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Aug 2019 04:59:58 +0000 Subject: [issue17305] IDNA2008 encoding is missing In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za> Message-ID: <1565758798.07.0.0467054380272.issue17305@roundup.psfhosted.org> Christian Heimes added the comment: You have to ask the Chrome team. ---------- versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 01:00:06 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 14 Aug 2019 05:00:06 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565758806.47.0.444088360129.issue37760@roundup.psfhosted.org> Change by Greg Price : ---------- pull_requests: +14985 pull_request: https://github.com/python/cpython/pull/15265 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 01:09:22 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Aug 2019 05:09:22 +0000 Subject: [issue37845] SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start In-Reply-To: <1565721204.27.0.66064229859.issue37845@roundup.psfhosted.org> Message-ID: <1565759362.92.0.279993865323.issue37845@roundup.psfhosted.org> Christian Heimes added the comment: This is not a bug in Python but a misconfiguration on your side. A workaround for a misconfiguration doesn't belong into upstream code. The certificate validation code is security-sensitive and I don't feel comfortable to add unnecessary string transformation to it. The code refuses bad wildcards because we have had more than one CVE related to wildcard matching. Besides the ssl.match_hostname() function is deprecated and no longer used. Starting with Python 3.7 the ssl module uses OpenSSL to verify host names. I suggest that you either ship this fix locally with your app. Or talk to IT again and have them replace the wrong certificate with a correct one that does not violate the standards. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 01:33:34 2019 From: report at bugs.python.org (Zackery Spytz) Date: Wed, 14 Aug 2019 05:33:34 +0000 Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za> Message-ID: <1565760814.94.0.496267903682.issue33012@roundup.psfhosted.org> Change by Zackery Spytz : ---------- pull_requests: +14986 pull_request: https://github.com/python/cpython/pull/14814 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 01:37:22 2019 From: report at bugs.python.org (Marcelo Salhab Brogliato) Date: Wed, 14 Aug 2019 05:37:22 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1565761042.52.0.169693251952.issue28747@roundup.psfhosted.org> Marcelo Salhab Brogliato added the comment: Exposing SSL_CTX_set_cert_verify_callback is useful when we want to use a Public Key Authentication, like it is done in the SSH Protocol. Do you know any other way to use Public Key Authentication besides using SSL_CTX_set_cert_verify_callback? ---------- nosy: +Marcelo Salhab Brogliato _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 01:42:20 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 14 Aug 2019 05:42:20 +0000 Subject: [issue37848] More fully implement Unicode's case mappings Message-ID: <1565761340.97.0.731805225537.issue37848@roundup.psfhosted.org> New submission from Greg Price : Splitting this out from #32771 for more specific discussion. Benjamin writes there that it would be good to: > implement the locale-specific case mappings of https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt and ?3.13 of the Unicode 12 standard in str.lower/upper/casefold. and adds that an implementation would require having available in the core the data on canonical combining classes, which is currently only in the unicodedata module. --- First, I'd like to better understand what functionality we have now and what else the standard describes. Reading https://www.unicode.org/Public/12.0.0/ucd/SpecialCasing.txt , I see * a bunch of rules that aren't language-specific * some other rules that are. I also see in makeunicodedata.py that we don't even parse the language-specific rules. Here's, IIUC, a demo of us correctly implementing the language-independent rules. One line in the data file reads: FB00; FB00; 0046 0066; 0046 0046; # LATIN SMALL LIGATURE FF And in fact the `lower`, `title`, and `upper` of `\uFB00` are those strings respectively: $ unicode --brief "$(./python -c \ 's="\ufb00"; print(" ".join((s.lower(), s.title(), s.upper())))')" ? U+FB00 LATIN SMALL LIGATURE FF U+0020 SPACE F U+0046 LATIN CAPITAL LETTER F f U+0066 LATIN SMALL LETTER F U+0020 SPACE F U+0046 LATIN CAPITAL LETTER F F U+0046 LATIN CAPITAL LETTER F OK, great. --- Then here's something we don't implement. Another line in the file reads: 00CD; 0069 0307 0301; 00CD; 00CD; lt; # LATIN CAPITAL LETTER I WITH ACUTE IOW `'\u00CD'` should lowercase to `'\u0069\u0307\u0301'`, i.e.: i U+0069 LATIN SMALL LETTER I ? U+0307 COMBINING DOT ABOVE ? U+0301 COMBINING ACUTE ACCENT ... but only in a Lithuanian (`lt`) locale. One question is: what would the right API for this be? I'm not sure I'd want `str.lower`'s results to depend on the process's current Unix locale... and I definitely wouldn't want to get that without some way of instead telling it what locale to use. (Either to use a single constant locale, or to use a per-user locale in e.g. a web application.) Perhaps `str.lower` and friends would take a keyword argument `locale`? Oh, one more link for reference: the said section of the standard is in this PDF: https://www.unicode.org/versions/Unicode12.0.0/ch03.pdf , near the end. And a related previous issue: #12736. ---------- components: Unicode messages: 349646 nosy: Greg Price, benjamin.peterson, ezio.melotti, lemburg, vstinner priority: normal severity: normal status: open title: More fully implement Unicode's case mappings versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 01:47:14 2019 From: report at bugs.python.org (Inada Naoki) Date: Wed, 14 Aug 2019 05:47:14 +0000 Subject: [issue37846] declare that Text I/O use buffer inside In-Reply-To: <1565750649.11.0.831019575323.issue37846@roundup.psfhosted.org> Message-ID: <1565761634.43.0.480109491677.issue37846@roundup.psfhosted.org> Inada Naoki added the comment: It's just an implementation detail. Python implementation and C implementation behave slightly different. But user program shouldn't rely on the detail. Why do you think implementation details should be declared? Who needs the information? ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 01:49:12 2019 From: report at bugs.python.org (Chih-Hsuan Yen) Date: Wed, 14 Aug 2019 05:49:12 +0000 Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za> Message-ID: <1565761752.38.0.109641500657.issue28747@roundup.psfhosted.org> Change by Chih-Hsuan Yen : ---------- nosy: -yan12125 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 01:51:09 2019 From: report at bugs.python.org (Inada Naoki) Date: Wed, 14 Aug 2019 05:51:09 +0000 Subject: [issue37337] Add _PyObject_VectorcallMethod() function In-Reply-To: <1560936931.61.0.893195452608.issue37337@roundup.psfhosted.org> Message-ID: <1565761869.29.0.425137492075.issue37337@roundup.psfhosted.org> Inada Naoki added the comment: New changeset 43d564c18c97421f73025ac3132a194975c76bd6 by Inada Naoki (Zackery Spytz) in branch 'master': bpo-37337: Fix a GCC 9 warning in Objects/descrobject.c (GH-14814) https://github.com/python/cpython/commit/43d564c18c97421f73025ac3132a194975c76bd6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 02:02:48 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 14 Aug 2019 06:02:48 +0000 Subject: [issue37848] More fully implement Unicode's case mappings In-Reply-To: <1565761340.97.0.731805225537.issue37848@roundup.psfhosted.org> Message-ID: <1565762568.86.0.825472959209.issue37848@roundup.psfhosted.org> Greg Price added the comment: Another previous discussion is #4610. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 02:06:48 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 14 Aug 2019 06:06:48 +0000 Subject: [issue32771] merge the underlying data stores of unicodedata and the str type In-Reply-To: <1517797199.65.0.467229070634.issue32771@psf.upfronthosting.co.za> Message-ID: <1565762808.57.0.555749838135.issue32771@roundup.psfhosted.org> Greg Price added the comment: OK, I forked off the discussion of case-mapping as #37848. I think it's probably good to first sort out what we want, before returning to how to implement it (if it's agreed that changes are desired.) Are there other areas of functionality that would be good to add in the core, and require data that's currently only in unicodedata? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 02:20:57 2019 From: report at bugs.python.org (Windson Yang) Date: Wed, 14 Aug 2019 06:20:57 +0000 Subject: [issue37846] declare that Text I/O use buffer inside In-Reply-To: <1565750649.11.0.831019575323.issue37846@roundup.psfhosted.org> Message-ID: <1565763657.71.0.452393653834.issue37846@roundup.psfhosted.org> Windson Yang added the comment: I found the document is not that clear when I try to understand what happens when Python read/write a file. I'm not sure who also needs this information. As you said, It wouldn't help the user program in Python. However, make it more clear maybe help users have a better feeling of what is happening under the hood. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 02:36:11 2019 From: report at bugs.python.org (Dong-hee Na) Date: Wed, 14 Aug 2019 06:36:11 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1565764571.19.0.832576672647.issue37798@roundup.psfhosted.org> Change by Dong-hee Na : ---------- keywords: +patch pull_requests: +14987 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15266 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 02:40:49 2019 From: report at bugs.python.org (Tal Einat) Date: Wed, 14 Aug 2019 06:40:49 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line Message-ID: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> New submission from Tal Einat : When the current line is near the bottom of the shell window, the completions list will be shown above it. However, instead of appearing directly above the current line, it appears quite a bit higher, about one line too high. See attached screenshot. Seen on Windows 10 with current master (2a570af12ac5e4ac5575a68f8739b31c24d01367). First brought up by Terry Reedy in a comment on PR GH-15169 [1]. [1] https://github.com/python/cpython/pull/15169#issuecomment-521066906 ---------- assignee: terry.reedy components: IDLE messages: 349652 nosy: taleinat, terry.reedy priority: normal severity: normal status: open title: IDLE: Completion window misplaced when shown above current line versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 02:45:26 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 Aug 2019 06:45:26 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565765126.43.0.981104609765.issue29535@roundup.psfhosted.org> Serhiy Storchaka added the comment: Other option is to remove a note about datetime hash. It is an implementation detail. There are other objects with nondeterministic hash, for example tuples containing strings, but we should not document this explicitly or make the hash of all tuples nondeterministic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 02:46:45 2019 From: report at bugs.python.org (Tal Einat) Date: Wed, 14 Aug 2019 06:46:45 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line In-Reply-To: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> Message-ID: <1565765205.36.0.112553935052.issue37849@roundup.psfhosted.org> Change by Tal Einat : Added file: https://bugs.python.org/file48541/idle_completion_window_position.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 02:48:20 2019 From: report at bugs.python.org (Tal Einat) Date: Wed, 14 Aug 2019 06:48:20 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line In-Reply-To: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> Message-ID: <1565765300.99.0.0734226188581.issue37849@roundup.psfhosted.org> Change by Tal Einat : ---------- keywords: +patch pull_requests: +14988 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15267 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 02:49:04 2019 From: report at bugs.python.org (Tal Einat) Date: Wed, 14 Aug 2019 06:49:04 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line In-Reply-To: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> Message-ID: <1565765344.84.0.637636069528.issue37849@roundup.psfhosted.org> Tal Einat added the comment: See PR GH-15267 with a fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 02:49:58 2019 From: report at bugs.python.org (Tal Einat) Date: Wed, 14 Aug 2019 06:49:58 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line In-Reply-To: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> Message-ID: <1565765398.05.0.237168923516.issue37849@roundup.psfhosted.org> Change by Tal Einat : ---------- pull_requests: +14989 pull_request: https://github.com/python/cpython/pull/15169 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 02:51:52 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 14 Aug 2019 06:51:52 +0000 Subject: [issue37847] The IDLE does not show previous code suggestions if I tap on the up arrow In-Reply-To: <1565753835.82.0.953640803878.issue37847@roundup.psfhosted.org> Message-ID: <1565765512.94.0.402439823854.issue37847@roundup.psfhosted.org> Terry J. Reedy added the comment: There are two ways to navigate history. 1. Shell menu, Previous History and Next History, which show the hot keys on your system. The hot keys can be customized with Options, Settings, Keys tab, history_prev, history_next. This is easily found by looking through the menu or the first part of the IDLE doc (Help, IDLE Help). 2. Click on previous line and hit Return. Should be somewhere in the IDLE Doc. #2704 includes a proposal to change arrow key behavior. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> IDLE: Patch to make PyShell behave more like a Terminal interface versions: +Python 3.9 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 02:52:57 2019 From: report at bugs.python.org (Tal Einat) Date: Wed, 14 Aug 2019 06:52:57 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line In-Reply-To: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> Message-ID: <1565765577.61.0.100037473046.issue37849@roundup.psfhosted.org> Change by Tal Einat : ---------- pull_requests: -14989 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 03:01:08 2019 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 14 Aug 2019 07:01:08 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565766068.0.0.404634138142.issue37831@roundup.psfhosted.org> Mark Dickinson added the comment: [Raymond] > Given that & | and ^ are closed under bools [...] So maybe the right fix is to change that fact? I'm not sure what the value of having True & True return True rather than 1 is, beyond misleading people into thinking that bitwise operators "just work" as logical operators on bools. Having True & True give 1 would send a clearer message that "yes, this works, but only because of the bool-is-an-int relationship, and it's not the right way to do logical operations". Does anyone know what the rationale was for having & and | on bools return bools in the first place? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 03:06:28 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 14 Aug 2019 07:06:28 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line In-Reply-To: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> Message-ID: <1565766388.36.0.719338086154.issue37849@roundup.psfhosted.org> Terry J. Reedy added the comment: What I reported is that it is too low on my Windows system, with my size and font, mostly covering the line. Anyway, misplaced before, now perfectly placed. Now that I see the patch, I seem to remember another place what an update call is needed before gathering window information. Unless you say differently, I will add idlelib/NEWS.txt item tomorrow and merge. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 03:11:46 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 14 Aug 2019 07:11:46 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 In-Reply-To: <1565618378.34.0.81940050082.issue37833@roundup.psfhosted.org> Message-ID: <1565766706.69.0.0804601979008.issue37833@roundup.psfhosted.org> Ronald Oussoren added the comment: Interestingly enough both users in the py2app issue I mentioned use the python.org installer to install Python. One of them mentions this only happens when py2app is used, and that the script works fine outside of an app. I'll look into this tonight (CEST). ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 03:30:48 2019 From: report at bugs.python.org (Aldwin Pollefeyt) Date: Wed, 14 Aug 2019 07:30:48 +0000 Subject: [issue5664] 2to3 wont convert Cookie.Cookie properly In-Reply-To: <1238642568.2.0.229238012255.issue5664@psf.upfronthosting.co.za> Message-ID: <1565767848.09.0.260217900266.issue5664@roundup.psfhosted.org> Change by Aldwin Pollefeyt : ---------- keywords: +patch pull_requests: +14990 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15268 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 03:33:17 2019 From: report at bugs.python.org (Aldwin Pollefeyt) Date: Wed, 14 Aug 2019 07:33:17 +0000 Subject: [issue5664] 2to3 wont convert Cookie.Cookie properly In-Reply-To: <1238642568.2.0.229238012255.issue5664@psf.upfronthosting.co.za> Message-ID: <1565767997.32.0.766275780276.issue5664@roundup.psfhosted.org> Change by Aldwin Pollefeyt : ---------- nosy: +aldwinaldwin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 03:40:52 2019 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 14 Aug 2019 07:40:52 +0000 Subject: [issue37848] More fully implement Unicode's case mappings In-Reply-To: <1565761340.97.0.731805225537.issue37848@roundup.psfhosted.org> Message-ID: <416f1fd6-6ec5-7fe6-58d5-faaa90a92bc7@egenix.com> Marc-Andre Lemburg added the comment: The Unicode implementation is deliberately not locale specific and this should not change. If a locale specific mapping is requested, this should be done explicitly by e.g. providing a parameter to str.lower() / upper() / title(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 04:08:29 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 Aug 2019 08:08:29 +0000 Subject: [issue37848] More fully implement Unicode's case mappings In-Reply-To: <1565761340.97.0.731805225537.issue37848@roundup.psfhosted.org> Message-ID: <1565770109.21.0.801971370231.issue37848@roundup.psfhosted.org> Serhiy Storchaka added the comment: I believe that all locale specific things should be in the locale module, not in the str class. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 04:15:14 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 Aug 2019 08:15:14 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565770514.3.0.157273908653.issue37831@roundup.psfhosted.org> Serhiy Storchaka added the comment: > Does anyone know what the rationale was for having & and | on bools return bools in the first place? Besides the fact that they can be defined on bool in compatible way and these operators often are used for booleans? It was in the initial version of PEP 285 and I have not found any questions or discussion about it. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 04:16:24 2019 From: report at bugs.python.org (Tal Einat) Date: Wed, 14 Aug 2019 08:16:24 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line In-Reply-To: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> Message-ID: <1565770584.4.0.614056519135.issue37849@roundup.psfhosted.org> Tal Einat added the comment: > Unless you say differently, I will add idlelib/NEWS.txt item tomorrow and merge. I've added an idlelib/NEWS.txt entry to the PR. Feel free to merge. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 04:18:11 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 Aug 2019 08:18:11 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565770691.3.0.986586741234.issue29535@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +14991 pull_request: https://github.com/python/cpython/pull/15269 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 04:18:40 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 14 Aug 2019 08:18:40 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565770720.61.0.369011800418.issue29535@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 04:45:03 2019 From: report at bugs.python.org (Michael Sander) Date: Wed, 14 Aug 2019 08:45:03 +0000 Subject: [issue23885] urllib.quote horribly mishandles unicode as second parameter In-Reply-To: <1428441015.17.0.142718858432.issue23885@psf.upfronthosting.co.za> Message-ID: <1565772303.34.0.802562136321.issue23885@roundup.psfhosted.org> Michael Sander added the comment: Couldn't this be fixed in a backwards compatible way by clearing the cache when this type of error occurs? We can do this by wrapping the offending line with a try/except, then checking to see if the cache is corrupted. If it is, then we clear the cache and try again. try: if not s.rstrip(safe): return s except UnicodeDecodeError: # Make sure the cache is okay, if not, try again. if any([not isinstance(s2, str) for q2, s2 in _safe_quoters.values()]) # Cache is corrupted, clear it and try again. _safe_quoters = {} # Recursive call to try again return quote(s, safe) raise ---------- nosy: +Michael Sander _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 05:50:36 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 09:50:36 +0000 Subject: =?utf-8?q?=5Bissue37681=5D_warning=3A_=E2=80=98no=5Fsanitize=5Fthread?= =?utf-8?b?4oCZ?= In-Reply-To: <1564070558.89.0.656147417061.issue37681@roundup.psfhosted.org> Message-ID: <1565776236.91.0.191759804249.issue37681@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 7e479c82218450255572e3f5fa1549dc283901ea by Victor Stinner (Hai Shi) in branch 'master': bpo-37681: no_sanitize_thread support from GCC 5.1 (GH-15096) https://github.com/python/cpython/commit/7e479c82218450255572e3f5fa1549dc283901ea ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 05:50:41 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 09:50:41 +0000 Subject: =?utf-8?q?=5Bissue37681=5D_warning=3A_=E2=80=98no=5Fsanitize=5Fthread?= =?utf-8?b?4oCZ?= In-Reply-To: <1564070558.89.0.656147417061.issue37681@roundup.psfhosted.org> Message-ID: <1565776241.23.0.201899153923.issue37681@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14992 pull_request: https://github.com/python/cpython/pull/15270 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 05:50:47 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 09:50:47 +0000 Subject: =?utf-8?q?=5Bissue37681=5D_warning=3A_=E2=80=98no=5Fsanitize=5Fthread?= =?utf-8?b?4oCZ?= In-Reply-To: <1564070558.89.0.656147417061.issue37681@roundup.psfhosted.org> Message-ID: <1565776247.76.0.189251381576.issue37681@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14993 pull_request: https://github.com/python/cpython/pull/15271 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 05:52:40 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 09:52:40 +0000 Subject: [issue37583] Got a 113 error when running the test_socket In-Reply-To: <1563006871.17.0.626459715079.issue37583@roundup.psfhosted.org> Message-ID: <1565776360.19.0.401509031824.issue37583@roundup.psfhosted.org> STINNER Victor added the comment: New changeset fbb0c032e89c42ab44f5372df40fffb34a91b575 by Victor Stinner (Hai Shi) in branch '3.7': bpo-37583: Add err 113 to support.get_socket_conn_refused_errs() (GH-15259) https://github.com/python/cpython/commit/fbb0c032e89c42ab44f5372df40fffb34a91b575 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 05:55:35 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 09:55:35 +0000 Subject: [issue37583] Got a 113 error when running the test_socket In-Reply-To: <1563006871.17.0.626459715079.issue37583@roundup.psfhosted.org> Message-ID: <1565776535.41.0.196236092786.issue37583@roundup.psfhosted.org> STINNER Victor added the comment: Thanks Hai Shi for the bug report and the fix. It's now fixd in 3.7, 3.8 and master branches. First I understood that you wanted to modify transient_internet() which is used in many places. Fixing support.get_socket_conn_refused_errs() is fine, it's only used in 2 test functions. I don't think that it's worth it to fix Python 2.7 (which doesn't have get_socket_conn_refused_errs() function but build errno list directly in test_socket). ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:08:50 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 10:08:50 +0000 Subject: =?utf-8?q?=5Bissue37681=5D_warning=3A_=E2=80=98no=5Fsanitize=5Fthread?= =?utf-8?b?4oCZ?= In-Reply-To: <1564070558.89.0.656147417061.issue37681@roundup.psfhosted.org> Message-ID: <1565777330.98.0.14933500342.issue37681@roundup.psfhosted.org> miss-islington added the comment: New changeset 364a1d3125af6c0ff0a4bd2c8afe70fd38f30456 by Miss Islington (bot) in branch '3.8': bpo-37681: no_sanitize_thread support from GCC 5.1 (GH-15096) https://github.com/python/cpython/commit/364a1d3125af6c0ff0a4bd2c8afe70fd38f30456 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:16:57 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 10:16:57 +0000 Subject: =?utf-8?q?=5Bissue37681=5D_warning=3A_=E2=80=98no=5Fsanitize=5Fthread?= =?utf-8?b?4oCZ?= In-Reply-To: <1564070558.89.0.656147417061.issue37681@roundup.psfhosted.org> Message-ID: <1565777817.95.0.735253334049.issue37681@roundup.psfhosted.org> miss-islington added the comment: New changeset 15b6d0a712c08557a605f49034f8ad392985144c by Miss Islington (bot) in branch '3.7': bpo-37681: no_sanitize_thread support from GCC 5.1 (GH-15096) https://github.com/python/cpython/commit/15b6d0a712c08557a605f49034f8ad392985144c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:19:24 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 10:19:24 +0000 Subject: [issue37848] More fully implement Unicode's case mappings In-Reply-To: <1565761340.97.0.731805225537.issue37848@roundup.psfhosted.org> Message-ID: <1565777964.11.0.571891593506.issue37848@roundup.psfhosted.org> STINNER Victor added the comment: Handling locales correctly is a pain. Each platform uses different locale names (different Linux distributions, Windows, FreeBSD, macOS, etc.). For example, en_US.UTF-8 vs en_US.utf8. For example, there are tons of bugs related to locale.getdefaultlocale() which tries to be smart on parsing locales. I'm fixing locale encoding bugs for 10 years and I'm not done yet: there are still many open bugs. I suggest you to first create a module on PyPI to experiment getting the locale and attempt to implement Unicode algorithms which depend on the locale. Maintaining Python is already expensive, I would prefer to not complicate the codebase too much with locales. There are already enough bugs waiting for you to be fixed ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:22:48 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 10:22:48 +0000 Subject: [issue32771] merge the underlying data stores of unicodedata and the str type In-Reply-To: <1517797199.65.0.467229070634.issue32771@psf.upfronthosting.co.za> Message-ID: <1565778168.69.0.206929510305.issue32771@roundup.psfhosted.org> STINNER Victor added the comment: Note: On Debian and Ubuntu, the unicodedata is a built-in module. It's not built as a dynamic library. About the RSS memory, I'm not sure how Linux accounts the Unicode databases before they are accessed. Is it like read-only memory loaded on demand when accessed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:25:36 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 10:25:36 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565778336.83.0.280142443658.issue37760@roundup.psfhosted.org> STINNER Victor added the comment: > From my perspective, the main problem with using type annotations is that there's nothing checking them in CI. Even if unchecked, type annotations can serve as builtin documentation, as docstrings (even when docstrings are not checked ;-)). Well, I don't have a strong opinion on type annotations in the Python stdlib. But here we are talking about a tool which is not installed, so I don't think that it matters much. It's not really part of the "stdlib". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:31:54 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 10:31:54 +0000 Subject: [issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information In-Reply-To: <1564667115.2.0.875397124654.issue37738@roundup.psfhosted.org> Message-ID: <1565778714.78.0.408799717741.issue37738@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +14994 pull_request: https://github.com/python/cpython/pull/15272 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:31:57 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 10:31:57 +0000 Subject: [issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information In-Reply-To: <1564667115.2.0.875397124654.issue37738@roundup.psfhosted.org> Message-ID: <1565778717.68.0.93999793349.issue37738@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 077af8c2c93dd71086e2c5e5ff1e634b6da8f214 by Victor Stinner in branch 'master': bpo-37738: Fix curses addch(str, color_pair) (GH-15071) https://github.com/python/cpython/commit/077af8c2c93dd71086e2c5e5ff1e634b6da8f214 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:40:10 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 14 Aug 2019 10:40:10 +0000 Subject: [issue37838] typing.get_type_hints not working with forward-declaration and decorated functions In-Reply-To: <1565692979.16.0.678723196671.issue37838@roundup.psfhosted.org> Message-ID: <1565779210.76.0.869325075387.issue37838@roundup.psfhosted.org> Change by Ivan Levkivskyi : ---------- keywords: +newcomer friendly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:40:24 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 10:40:24 +0000 Subject: [issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information In-Reply-To: <1564667115.2.0.875397124654.issue37738@roundup.psfhosted.org> Message-ID: <1565779224.62.0.64657216927.issue37738@roundup.psfhosted.org> STINNER Victor added the comment: On my Fedora 30 with libncursesw, A_COLOR = 0xff00. After my change, _curses uses: static inline short attr_to_color_pair(int attr) { return (short)((attr & A_COLOR) >> 8); } ... setcchar(&wcval, wstr, attr, attr_to_color_pair(attr), NULL); ... If someone gets troubles with attr passed "directly" as the 3rd argument of setcchar(), we can try to pass (attr & ~A_COLOR) instead. On my Linux, it would mean: only pass the low 8 bits of attr. But since it "just" works on my Linux, I prefer to only make minimum changes to fix this issue on Linux. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:41:55 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 10:41:55 +0000 Subject: [issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information In-Reply-To: <1564667115.2.0.875397124654.issue37738@roundup.psfhosted.org> Message-ID: <1565779315.36.0.661173850261.issue37738@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +14995 pull_request: https://github.com/python/cpython/pull/15273 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:46:31 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 10:46:31 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1565779591.78.0.145391090119.issue37531@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +14996 pull_request: https://github.com/python/cpython/pull/15072 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:49:16 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 10:49:16 +0000 Subject: [issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information In-Reply-To: <1564667115.2.0.875397124654.issue37738@roundup.psfhosted.org> Message-ID: <1565779756.7.0.205795593668.issue37738@roundup.psfhosted.org> miss-islington added the comment: New changeset 984226962bc35254551d92771b5c8fb074507903 by Miss Islington (bot) in branch '3.8': bpo-37738: Fix curses addch(str, color_pair) (GH-15071) https://github.com/python/cpython/commit/984226962bc35254551d92771b5c8fb074507903 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 06:59:51 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 10:59:51 +0000 Subject: =?utf-8?q?=5Bissue37681=5D_warning=3A_=E2=80=98no=5Fsanitize=5Fthread?= =?utf-8?b?4oCZ?= In-Reply-To: <1564070558.89.0.656147417061.issue37681@roundup.psfhosted.org> Message-ID: <1565780391.57.0.242485416451.issue37681@roundup.psfhosted.org> STINNER Victor added the comment: Thanks Hai Shi for the bug report and the fix. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 07:00:30 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 11:00:30 +0000 Subject: [issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information In-Reply-To: <1564667115.2.0.875397124654.issue37738@roundup.psfhosted.org> Message-ID: <1565780430.5.0.16429493091.issue37738@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 7eef81ee766c8df23e522b4e46a930cc1d360ad7 by Victor Stinner in branch '3.7': bpo-37738: Fix curses addch(str, color_pair) (GH-15071) (GH-15273) https://github.com/python/cpython/commit/7eef81ee766c8df23e522b4e46a930cc1d360ad7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 07:01:28 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 11:01:28 +0000 Subject: [issue37738] curses.addch('a', curses.color_pair(1)) ignores the color information In-Reply-To: <1564667115.2.0.875397124654.issue37738@roundup.psfhosted.org> Message-ID: <1565780488.97.0.183428623553.issue37738@roundup.psfhosted.org> STINNER Victor added the comment: I fixed the bug in 3.7, 3.8 and master (future 3.9) branches. Thanks Marius Gedminas for the bug report. In the meanwhile, you have to pass bytes strings to addch() :-( ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 07:05:23 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 11:05:23 +0000 Subject: [issue36502] str.isspace() for U+00A0 and U+202F differs from document In-Reply-To: <1554186967.56.0.21483381742.issue36502@roundup.psfhosted.org> Message-ID: <1565780723.35.0.179550960749.issue36502@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 6bccbe7dfb998af862a183f2c36f0d4603af2c29 by Victor Stinner (Greg Price) in branch 'master': bpo-36502: Correct documentation of str.isspace() (GH-15019) https://github.com/python/cpython/commit/6bccbe7dfb998af862a183f2c36f0d4603af2c29 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 07:05:36 2019 From: report at bugs.python.org (Matthijs Blom) Date: Wed, 14 Aug 2019 11:05:36 +0000 Subject: [issue37850] Console: holding right arrow key reproduces entire previous input Message-ID: <1565780736.93.0.23974280241.issue37850@roundup.psfhosted.org> New submission from Matthijs Blom : To reproduce (on Windows): On the console, enter some input: >>> "Ozewiezewoze wiezewalla kristalla" "Ozewiezewoze wiezewalla kristalla" Next, hold the right arrow key, obtaining: >>> "Ozewiezewoze wiezewalla kristalla" One can subsequently delete sections of this line and again reproduce (last parts of) the previous input. I have produced this result on 3.4, 3.8.0b3 and master (077af8c). I did not observe this behaviour on WSL, which is why I think this is a bug. ---------- components: Windows messages: 349679 nosy: Matthijs Blom, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Console: holding right arrow key reproduces entire previous input type: behavior versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 07:19:29 2019 From: report at bugs.python.org (Paul Moore) Date: Wed, 14 Aug 2019 11:19:29 +0000 Subject: [issue37850] Console: holding right arrow key reproduces entire previous input In-Reply-To: <1565780736.93.0.23974280241.issue37850@roundup.psfhosted.org> Message-ID: <1565781569.59.0.361429705224.issue37850@roundup.psfhosted.org> Paul Moore added the comment: This is normal behaviour of the Windows console command line editing. Python simply inherits the standard console behaviour. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 07:24:59 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 11:24:59 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565781899.86.0.65140065402.issue21131@roundup.psfhosted.org> STINNER Victor added the comment: I dislike PR 13649 because it touch the thread module, only to fix a faulthandler unit test. The relationship between thread stack size and faulthandler is not obvious to me. Currently, faulthandler uses SIGSTKSZ, not the thread stack size. faulthandler usage of the stack should be quite low: it should need less than 1 MiB for example. "When faulthandler.c uses sigaltstack(2), the stack size is set up with a buffer of size SIGSTKSZ. That is, sadly, only 8k." "A chained signal handler that needs to invoke dynamic linking will therefore consume more than the default stack space allocated in faulthandler.c, just in machine-state saves alone. So, the failing test is failing because its scribbling on random memory before the allocated stack space." Aha, that's interesting: SIGSTKSZ should be enough for 1 signal handler, but test_register_chain calls 2 signal handlers using the same stack. Can you please try the following patch? diff --git a/Modules/faulthandler.c b/Modules/faulthandler.c index 2331051f79..e7d13f2b2d 100644 --- a/Modules/faulthandler.c +++ b/Modules/faulthandler.c @@ -1325,7 +1325,7 @@ _PyFaulthandler_Init(int enable) * be able to allocate memory on the stack, even on a stack overflow. If it * fails, ignore the error. */ stack.ss_flags = 0; - stack.ss_size = SIGSTKSZ; + stack.ss_size = SIGSTKSZ * 2; stack.ss_sp = PyMem_Malloc(stack.ss_size); if (stack.ss_sp != NULL) { err = sigaltstack(&stack, &old_stack); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 07:25:09 2019 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Wed, 14 Aug 2019 11:25:09 +0000 Subject: [issue34311] locale.format() and locale.format_string() cast Decimals to float In-Reply-To: <1533154971.69.0.56676864532.issue34311@psf.upfronthosting.co.za> Message-ID: <1565781909.35.0.676614828908.issue34311@roundup.psfhosted.org> Change by C?dric Krier : ---------- pull_requests: +14997 pull_request: https://github.com/python/cpython/pull/15275 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 07:28:50 2019 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Wed, 14 Aug 2019 11:28:50 +0000 Subject: [issue34311] locale.format() and locale.format_string() cast Decimals to float In-Reply-To: <1533154971.69.0.56676864532.issue34311@psf.upfronthosting.co.za> Message-ID: <1565782130.74.0.362468462112.issue34311@roundup.psfhosted.org> C?dric Krier added the comment: I think we can solve this issue like I solved issue13918 by providing a locale.localize() method which does the formatting as locale.format_string does but using the already formatted string. I created PR-15275 which implements it and also use the new format in locale.currency as it is highly probable that currency will be used with Decimal. ---------- nosy: +ced _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 07:34:15 2019 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Wed, 14 Aug 2019 11:34:15 +0000 Subject: [issue33731] string formatting that produces floats with preset precision while respecting locale In-Reply-To: <1527856953.25.0.682650639539.issue33731@psf.upfronthosting.co.za> Message-ID: <1565782455.23.0.676119412223.issue33731@roundup.psfhosted.org> C?dric Krier added the comment: I think PR-15275 will solves this issue also as you could use: >>> locale.setlocale(locale.LC_ALL, 'fr_FR') >>> locale.localize('{:.2f}'.format(1.891)) '1,89' ---------- nosy: +ced _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 07:35:27 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Wed, 14 Aug 2019 11:35:27 +0000 Subject: [issue37774] Micro-optimize vectorcall using PY_LIKELY In-Reply-To: <1565100015.93.0.140823146757.issue37774@roundup.psfhosted.org> Message-ID: <1565782527.29.0.179093361446.issue37774@roundup.psfhosted.org> Jeroen Demeyer added the comment: > My question is if it is safe to let developers "abuse" it. If these macros are misused, they can lead to a performance regression. I expect people using these macros and PR reviewers to use good judgement when to use these macros. There are many cases where the use of such macros should be uncontroversial, for example when checking for errors. > For example, if you mark the error path as unlikely: this path will become slower. If the error path is taken "frequently" enough, the slowdown can become significant overall. The speedup/slowdown that Py_LIKELY/Py_UNLIKELY gives is quite small, just a few clock cycles. This means that we shouldn't worry about performance regressions if the rest of the code takes much longer anyway. An example of this is raising exceptions, which typically involves PyErr_Format(). So I wouldn't worry too much about error paths getting slower. > About the macros, I would prefer to make it private to not promote it. I don't think it matters whether we call it Py_LIKELY or _Py_LIKELY. People that want to use it will use it anyway. And there is no issue with "provisional API" since this API is well-established in many existing projects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 07:42:02 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 11:42:02 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565782922.88.0.589773361066.issue21131@roundup.psfhosted.org> STINNER Victor added the comment: Attached altstack.c mimicks faulthandler unit test test_register_chain(), except that faulthandler_user() uses almost no stack memory. This test should check if SIGSTKSZ is big enough to call a second signal handler from a first signal handler. Example of my Fedora 30 with "Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz" model name in /proc/cpuinfo and Linux kernel 5.1.18-300.fc30.x86_64: $ gcc altstack.c -o altstack && ./altstack SIGSTKSZ = 8192 our signal handler User defined signal 1 Note: the follow gdb command didn't work for me: > (gdb) p _rtld_local_ro._dl_x86_cpu_features.xsave_state_size > $1 = 896 How can I get xsave_state_size for my glibc/kernel/CPU? ---------- Added file: https://bugs.python.org/file48542/altstack.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 07:48:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 11:48:39 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565783319.65.0.609013648617.issue21131@roundup.psfhosted.org> STINNER Victor added the comment: Ah, the cpuid command tells me "bytes required by XSAVE/XRSTOR area = 1088": CPU 0: vendor_id = "GenuineIntel" version information (1/eax): processor type = primary processor (0) family = Intel Pentium Pro/II/III/Celeron/Core/Core 2/Atom, AMD Athlon/Duron, Cyrix M2, VIA C3 (6) model = 0xe (14) stepping id = 0x3 (3) extended family = 0x0 (0) extended model = 0x5 (5) (simple synth) = Intel Core i3-6000 / i5-6000 / i7-6000 / Pentium G4000 / Celeron G3900 / Xeon E3-1200 (Skylake), 14nm ... feature information (1/edx): FXSAVE/FXRSTOR = true ... feature information (1/ecx): XSAVE/XSTOR states = true OS-enabled XSAVE/XSTOR = true ... XSAVE features (0xd/0): bytes required by XSAVE/XRSTOR area = 0x00000440 (1088) ... XSAVE features (0xd/1): XSAVEOPT instruction = true XSAVEC instruction = true XSAVES/XRSTORS instructions = true ... /proc/cpuinfo also says: flags : ... xsave avx ... xsaveopt xsavec xgetbv1 xsaves ... I recall that the Linux kernel was modified to only save AVX registers if a program uses AVX. So the process state size depends on the usage of AVX. But I cannot find the related LWN article. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 08:18:16 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 12:18:16 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565785096.9.0.623804607714.issue21131@roundup.psfhosted.org> STINNER Victor added the comment: Ah, I found the recent change about XSAVE: it is a fix for CVE-2018-3665 vulnerability. "The software mitigation for this is to switch to an "eager" / immediate FPU state save and restore, in both kernels and hypervisors." "On Intel and AMD x86 processors, operating systems and hypervisors often use what is referred to as a deferred saving and restoring method of the x86 FPU state, as part of performance optimization. This is done in a "lazy" on-demand fashion." "It was found that due to the "lazy" approach, the x86 FPU states or FPU / XMM / AVX512 register content, could leak across process, or even VM boundaries, giving attackers possibilities to read private data from other processes, when using speculative execution side channel gadgets." https://www.suse.com/support/kb/doc/?id=7023076 See also: https://en.wikipedia.org/wiki/Lazy_FP_state_restore ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 08:18:57 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 12:18:57 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1565785137.89.0.519220812439.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: New changeset b0c8369c603633f445ccbb5ca7a8742145ff9eec by Victor Stinner in branch 'master': bpo-37531: Fix regrtest timeout for subprocesses (GH-15072) https://github.com/python/cpython/commit/b0c8369c603633f445ccbb5ca7a8742145ff9eec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 08:24:08 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 12:24:08 +0000 Subject: [issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc In-Reply-To: <1563731175.2.0.136240000148.issue37645@roundup.psfhosted.org> Message-ID: <1565785448.22.0.192386022326.issue37645@roundup.psfhosted.org> STINNER Victor added the comment: Maybe repr(func) should be left unchanged, but str(func) can be enhanced? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 08:45:05 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Wed, 14 Aug 2019 12:45:05 +0000 Subject: [issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc In-Reply-To: <1563731175.2.0.136240000148.issue37645@roundup.psfhosted.org> Message-ID: <1565786705.43.0.778461483447.issue37645@roundup.psfhosted.org> Jeroen Demeyer added the comment: > Maybe repr(func) should be left unchanged, but str(func) can be enhanced? Yes, that is what I meant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 08:45:45 2019 From: report at bugs.python.org (Peter Edwards) Date: Wed, 14 Aug 2019 12:45:45 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1565781899.86.0.65140065402.issue21131@roundup.psfhosted.org> Message-ID: Peter Edwards added the comment: Hi Victor, thanks for the comments. Responses inline below. On Wed, 14 Aug 2019 at 12:25, STINNER Victor wrote: > > STINNER Victor added the comment: > > I dislike PR 13649 because it touch the thread module, only to fix a > faulthandler unit test. My original patch (posted in the comments above) was purely in faulthandler - I went at the threading code on your suggestion: PyThread_start_new_thread() of thread_pthread.h already contains logic to > get a "good" stack size. I would prefer to reuse this code." I have no problem reformulating the code to avoid touching the threads library - let me redo it as such. > The relationship between thread stack size and faulthandler is not obvious > to me. Currently, faulthandler uses SIGSTKSZ, not the thread stack size. > faulthandler usage of the stack should be quite low: it should need less > than 1 MiB for example. > The point of contention here is really he choice of stack size. SIGSTKSZ is ridiculously small - it is the bare minimum amount of memory required to actually handle the signal. The signal handling mechanism eats a huge chunk of it, and the dynamic linker can also eat several K too. The intent was to use the default thread stack size as a heuristic for what the platform considers to be a reasonable size stack for applications. If the pthread-aware OS is somehow constrained for address space, then I'd expect it to reflect that in the default stack size. For 32-bit linux, the 8M of address space is a bit of a chunk, but it's not a huge proportion of the 3-4G you have, and you're not consuming actual memory. On a 64-bit system, consuming 8M of address space is a drop in the ocean. > > "When faulthandler.c uses sigaltstack(2), the stack size is set up with a > buffer of size SIGSTKSZ. That is, sadly, only 8k." > > "A chained signal handler that needs to invoke dynamic linking will > therefore consume more than the default stack space allocated in > faulthandler.c, just in machine-state saves alone. So, the failing test is > failing because its scribbling on random memory before the allocated stack > space." > > Aha, that's interesting: SIGSTKSZ should be enough for 1 signal handler, > but test_register_chain calls 2 signal handlers using the same stack. Can > you please try the following patch? > It's more complex than that - in dynamically linked applications when you call functions that still need to be resolved by the dynamic linker, the resolving thunk in the PLT also ends up saving the register state via xsavec, so with a chained call, there are up to 3 register states saved on the stack, each over 2.5k on actual hardware we have now. I'm not convinced there are not other ways stack space will be consumed during the signal handler, and I'm not convinced that the amount of memory required per handler will not go up as new CPUs come out, and I'm not convinced that SIGSTKSZ will be bumped to reflect that (it certainly hasn't in the past), so scaling SIGSTKSZ like this, while it'll likely fix the problem on any machine I can test it on, doesn't seem like a stable solution > diff --git a/Modules/faulthandler.c b/Modules/faulthandler.c > index 2331051f79..e7d13f2b2d 100644 > --- a/Modules/faulthandler.c > +++ b/Modules/faulthandler.c > @@ -1325,7 +1325,7 @@ _PyFaulthandler_Init(int enable) > * be able to allocate memory on the stack, even on a stack overflow. > If it > * fails, ignore the error. */ > stack.ss_flags = 0; > - stack.ss_size = SIGSTKSZ; > + stack.ss_size = SIGSTKSZ * 2; > stack.ss_sp = PyMem_Malloc(stack.ss_size); > if (stack.ss_sp != NULL) { > err = sigaltstack(&stack, &old_stack); > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 09:02:18 2019 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 14 Aug 2019 13:02:18 +0000 Subject: [issue37830] continue and break in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1565787738.64.0.534975356011.issue37830@roundup.psfhosted.org> Nick Coghlan added the comment: Even though it doesn't fully resolve this crash, I'd still like us to consider reverting the change to allow "continue" in try/finally blocks. It doesn't seem to have a compelling practical motivation behind it (beyond the fact that it's nice not to impose arbitrary restriction on users), and even if it's feasible in CPython now, it still creates a non-trivial amount of work for other Python implementations that are trying to remain consistent with what CPython allows. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 09:26:19 2019 From: report at bugs.python.org (Bennet Fauber) Date: Wed, 14 Aug 2019 13:26:19 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565789179.05.0.894140639007.issue21131@roundup.psfhosted.org> Bennet Fauber added the comment: I just tested the proposed change in Aha, that's interesting: SIGSTKSZ should be enough for 1 signal handler, but test_register_chain calls 2 signal handlers using the same stack. Can you please try the following patch? ``` diff --git a/Modules/faulthandler.c b/Modules/faulthandler.c index 2331051f79..e7d13f2b2d 100644 --- a/Modules/faulthandler.c +++ b/Modules/faulthandler.c . . . . - stack.ss_size = SIGSTKSZ; + stack.ss_size = SIGSTKSZ * 2; ``` and the segfault no longer occurs at the faulthandler test. Compiling and running the altstack.c using the system installed GCC 4.8.5 on CentOS 7.6.1810, kernel version 3.10.0-957.10.1.el7.x86_64 running on Dell R640 Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz results in this output. ``` $ gcc -o altstack altstack.c $ ./altstack SIGSTKSZ = 8192 our signal handler User defined signal 1 ``` It does seem to me that relying on a statically set stack size when using dynamically loaded libraries is inviting similar problems in the future for the reasons that Peter enumerated: There is no telling now what the requirements will be for some new chip family, and one cannot predict now what additional (if any) memory requirements might be needed by the linker in the future. But, I think getting _some_ patch accepted and pushed to the main Python releases should have some priority, as the current state does seem undesirable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 09:34:38 2019 From: report at bugs.python.org (Peter Edwards) Date: Wed, 14 Aug 2019 13:34:38 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1565789179.05.0.894140639007.issue21131@roundup.psfhosted.org> Message-ID: Peter Edwards added the comment: The patch I originally proposed here ( https://bugs.python.org/file48353/sigaltstack-stacksize.patch ) is a pretty minimal fix that uses the pthread stack size where available, with a hard-coded lower bound of 1M. @Victor : if you want a minimal diff, I can drop the existing PR, submit the above as a new one, and we can progress from there? Let me know how you'd like me to proceed. On Wed, 14 Aug 2019 at 14:26, Bennet Fauber wrote: > > Bennet Fauber added the comment: > > I just tested the proposed change in > > Aha, that's interesting: SIGSTKSZ should be enough for 1 signal handler, > but test_register_chain calls 2 signal handlers using the same stack. Can > you please try the following patch? > > ``` > diff --git a/Modules/faulthandler.c b/Modules/faulthandler.c > index 2331051f79..e7d13f2b2d 100644 > --- a/Modules/faulthandler.c > +++ b/Modules/faulthandler.c > . . . . > - stack.ss_size = SIGSTKSZ; > + stack.ss_size = SIGSTKSZ * 2; > ``` > > and the segfault no longer occurs at the faulthandler test. > > Compiling and running the altstack.c using the system installed GCC 4.8.5 > on CentOS 7.6.1810, kernel version 3.10.0-957.10.1.el7.x86_64 running on > Dell R640 Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz results in this output. > > ``` > $ gcc -o altstack altstack.c > $ ./altstack > SIGSTKSZ = 8192 > our signal handler > User defined signal 1 > ``` > > It does seem to me that relying on a statically set stack size when using > dynamically loaded libraries is inviting similar problems in the future for > the reasons that Peter enumerated: There is no telling now what the > requirements will be for some new chip family, and one cannot predict now > what additional (if any) memory requirements might be needed by the linker > in the future. > > But, I think getting _some_ patch accepted and pushed to the main Python > releases should have some priority, as the current state does seem > undesirable. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 09:37:44 2019 From: report at bugs.python.org (David K.) Date: Wed, 14 Aug 2019 13:37:44 +0000 Subject: [issue37845] SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start In-Reply-To: <1565759362.92.0.279993865323.issue37845@roundup.psfhosted.org> Message-ID: David K. added the comment: Hi, Judging by your comment, I think there is a an unfortnate misunderstanding. If you'd be kind enough, please let me explain: 1. The issue I had was indeed on Python 3.7, using the highly used "requests" library. Also my change was -not- applied on the deprecated ssl.match_hostname() but on _dnsname_match() which is a method of another inner class. My point is that it's still releveant. 2. Although there is a thin line here, it is not a configuration issue by its classic meaning. It's an outside condition in a production environment that unpatches Python code cannot handle and thus implicating that Python is less stable and mistake tolerant than C# and Java (those are the other more used languages in the company which weren't effected by this problem -- for some who wouldn't bother like me to patch python source code, this could be a deal breaker to move to another language). 3. It's a very simple fix that only removes white spaces (empty chars) from start and end of the DNS before applying all the other tests on it. In fact by assuring the input of the DNS name, our code becomes -more- secure. In current state, a missed type DNS name encoded in the certifications could cause unknowingly Python deamons to stop transmiting data. Also as humans tend to make such naive errors, a mallicious party could make an attack be seemless and be discarded as human error. And if that doesn't convince you, we can say at the very least the service we provide with our App becomes unusable and unavailable to clients and for some that could cost time and money and Python may take the blame as unreliable as compared to other languages. 4. The thrown exception can be misleading: The exception says that the problem is a partial wildcard. However the problem is white spaces which can be difficult to spot. White spaces cannot be part of DNS names thus it makes no sense to ackonwledge them or refer to them or event test them as any other legit legal char. Also this is unpredictible to the programmer as he wouldn't think such a basic trim/strip of white spaces wouldn't happen in the core of the SSL code what's worse, it can't be handled conventialy with catching the exception. While a programmer can edit Python source code to it's needs, they really shouldn't mess with it for more than a short term use. Declining the change dooms me for example to always add this change to projects using SSL. Thank you for your time. I truely hope we can resolve this. D.K On Wed, Aug 14, 2019, 08:09 Christian Heimes wrote: > > Christian Heimes added the comment: > > This is not a bug in Python but a misconfiguration on your side. A > workaround for a misconfiguration doesn't belong into upstream code. The > certificate validation code is security-sensitive and I don't feel > comfortable to add unnecessary string transformation to it. The code > refuses bad wildcards because we have had more than one CVE related to > wildcard matching. > > Besides the ssl.match_hostname() function is deprecated and no longer > used. Starting with Python 3.7 the ssl module uses OpenSSL to verify host > names. > > I suggest that you either ship this fix locally with your app. Or talk to > IT again and have them replace the wrong certificate with a correct one > that does not violate the standards. > > ---------- > resolution: -> rejected > stage: patch review -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 09:41:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 13:41:25 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565790085.63.0.592378404228.issue21131@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +14999 pull_request: https://github.com/python/cpython/pull/15276 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 09:41:28 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 13:41:28 +0000 Subject: [issue37256] urllib.request.Request documentation erroneously refers to the "final two" In-Reply-To: <1560366755.97.0.221740241329.issue37256@roundup.psfhosted.org> Message-ID: <1565790088.28.0.602190875725.issue37256@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15000 pull_request: https://github.com/python/cpython/pull/15277 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 09:41:34 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 13:41:34 +0000 Subject: [issue37256] urllib.request.Request documentation erroneously refers to the "final two" In-Reply-To: <1560366755.97.0.221740241329.issue37256@roundup.psfhosted.org> Message-ID: <1565790094.52.0.39542133054.issue37256@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15001 pull_request: https://github.com/python/cpython/pull/15278 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 09:44:00 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 13:44:00 +0000 Subject: [issue37851] faulthandler: only allocate the signal handler stack when faulthandler is used Message-ID: <1565790240.15.0.788753710363.issue37851@roundup.psfhosted.org> New submission from STINNER Victor : Currently at startup, Python always call _PyFaulthandler_Init() which allocates a stack of SIGSTKSZ bytes, even if faulthandler is never used. That's a waste of memory: the stack should be allocated the first time faulthandler is used. bpo-21131 requires to enlarge this stack size. ---------- components: Library (Lib) messages: 349697 nosy: vstinner priority: normal severity: normal status: open title: faulthandler: only allocate the signal handler stack when faulthandler is used versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 09:45:58 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 13:45:58 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565790358.78.0.895060554501.issue21131@roundup.psfhosted.org> STINNER Victor added the comment: "On a 64-bit system, consuming 8M of address space is a drop in the ocean." Let me disagree here. Python always allocates faulthandler stack, even if faulthandler is not used. Even when faulthandler is used, I would prefer to not waste memory if 8 KiB is good enough. By the way, I just created bpo-37851 to allocate this stack at the first faulthandler usage, instead of always allocating it, even when faulthandler is not used. I wrote PR 15276 to use a stack of SIGSTKSZ*2 bytes. According to msg349694, it does fix the crash. Can someone please double check that PR 15276 fix test_faulthandler on a platform where the test crash without this change? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 09:55:57 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 13:55:57 +0000 Subject: [issue37256] urllib.request.Request documentation erroneously refers to the "final two" In-Reply-To: <1560366755.97.0.221740241329.issue37256@roundup.psfhosted.org> Message-ID: <1565790957.69.0.548033102385.issue37256@roundup.psfhosted.org> miss-islington added the comment: New changeset 3e1f135b26cf5fb3583d7e75d39b7b7a9edb472c by Miss Islington (bot) in branch '3.7': bpo-37256: Wording in Request class docs (GH-14792) https://github.com/python/cpython/commit/3e1f135b26cf5fb3583d7e75d39b7b7a9edb472c ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 09:56:14 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 13:56:14 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1565790974.23.0.299044458082.issue37531@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15002 pull_request: https://github.com/python/cpython/pull/15279 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 09:56:14 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 13:56:14 +0000 Subject: [issue36511] Add Windows ARM32 buildbot In-Reply-To: <1554232161.58.0.393661272603.issue36511@roundup.psfhosted.org> Message-ID: <1565790974.3.0.952375019386.issue36511@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15003 pull_request: https://github.com/python/cpython/pull/15279 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:04:08 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 14:04:08 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1565791448.93.0.105244449471.issue37531@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15004 pull_request: https://github.com/python/cpython/pull/15280 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:10:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 14:10:39 +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: <1565791839.41.0.555518758547.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 4fa10dde40356d7c71e5524233bafc221d9e2deb by Victor Stinner (Sergey Fedoseev) in branch 'master': bpo-36030: Improve performance of some tuple operations (GH-12052) https://github.com/python/cpython/commit/4fa10dde40356d7c71e5524233bafc221d9e2deb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:11:29 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 14:11:29 +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: <1565791889.99.0.920204398636.issue36030@roundup.psfhosted.org> STINNER Victor added the comment: Well done Sergey Fedoseev: I merged your last PR for this issue ;-) I'm not sure if it's worth it to document these tuple micro-optimizations in What's New in Python 3.8 / 3.9. In the meanwhile, I close the issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:23:51 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Aug 2019 14:23:51 +0000 Subject: [issue37845] SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start In-Reply-To: Message-ID: <3a325ab0-fcb2-cc66-70b4-9e6a42d3ad61@cheimes.de> Christian Heimes added the comment: On 14/08/2019 15.37, David K. wrote: > > David K. added the comment: > > Hi, > > Judging by your comment, I think there is a an unfortnate misunderstanding. > > If you'd be kind enough, please let me explain: > > 1. The issue I had was indeed on Python 3.7, using the highly used > "requests" library. Also my change was -not- applied on the deprecated > ssl.match_hostname() > but on _dnsname_match() which is a method of another inner class. > My point is that it's still releveant. Except it's not revelant any more because that function is no longer used by CPython's ssl module. Neither match_hostname nor any of its helper functions are called by code in the ssl module. Since 3.7 all hostname verification is now performed by OpenSSL code directly. ssl.match_hostname will be removed in 3.9 or 3.10. Latest urllib3 and requests don't use ssl.match_hostname() either. The urllib3 package has an older copy of the hostname matching algorithm in urllib3.packages.ssl_match_hostname. It should not be used with modern Python. > 2. Although there is a thin line here, it is not a configuration issue by > its classic meaning. It's an outside condition in a production environment > that unpatches Python code cannot handle and thus implicating that Python > is less stable and mistake tolerant than C# and Java (those are the other > more used languages in the company which weren't effected by this problem > -- for some who wouldn't bother like me to patch python source code, this > could be a deal breaker to move to another language). Your setup has a misconfigured X.509 certificate with a SAN entry that violates standards for certificates. You are asking me to introduce a security into Python as a workaround for the misconfiguration. The algorithm in match_hostname() and _dnsname_match() implements RFC 6125, section 6.4.3, in a strict way. Python not only refuses to match invalid wildcard entries, it also fails hard on RFC 6125 violations. > 3. It's a very simple fix that only removes white spaces (empty chars) from > start and end of the DNS before applying all the other tests on it. In fact > by assuring the input of the DNS name, our code becomes -more- secure. In > current state, a missed type DNS name encoded in the certifications could > cause unknowingly Python deamons to stop transmiting data. Also as humans > tend to make such naive errors, a mallicious party could make an attack be > seemless and be discarded as human error. And if that doesn't convince > you, we can say at the very least the service we provide with our App > becomes unusable and unavailable to clients and for some that could cost > time and money and Python may take the blame as unreliable as compared to > other languages. You view the fix as simple and harmless. I see it as a violation of standards and a security bug. X.509 certs are complex and fragile beasts. Python have had several CVEs in the hostname matching code because we didn't implement it correctly. Certificates are also used in legal contracts, e.g. to legally sign documents or establish mutual trust. You cannot just modify the content of a certificate. Since you are worried about the reliability of Python and started talking about money, have you considered to donate money to the PSF? Python is maintained by unpaid volunteers. Donations to the Python Software Foundation help. (Disclaimer: No money in the world will change my opinion about "dn.strip()".) > 4. The thrown exception can be misleading: The exception says that the > problem is a partial wildcard. However the problem is white spaces which > can be difficult to spot. White spaces cannot be part of DNS names thus it > makes no sense to ackonwledge them or refer to them or event test them as > any other legit legal char. Also this is unpredictible to the programmer as > he wouldn't think such a basic trim/strip of white spaces wouldn't happen > in the core of the SSL code what's worse, it can't be handled conventialy > with catching the exception. While a programmer can edit Python source code > to it's needs, they really shouldn't mess with it for more than a short > term use. Declining the change dooms me for example to always add this > change to projects using SSL. The problem is not the code but the certificate. If you don't care about valid certificate, then maybe disable hostname / certificate verification. Or role your own verification. There is no need to modify any source code for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:30:59 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 14:30:59 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1565793059.99.0.855362169424.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 93bee6a8d878ff952e245614c567c7c6bb7a0398 by Victor Stinner in branch '3.7': [3.7] bpo-37531: Fix regrtest timeout for subprocesses (GH-15072) (GH-15280) https://github.com/python/cpython/commit/93bee6a8d878ff952e245614c567c7c6bb7a0398 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:31:35 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 14:31:35 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1565793095.7.0.922641882672.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: New changeset d85c5670ff1611202a25c9e0967148e72c114de9 by Victor Stinner in branch '3.8': [3.8] bpo-37531: Fix regrtest timeout for subprocesses (GH-15072) (GH-15279) https://github.com/python/cpython/commit/d85c5670ff1611202a25c9e0967148e72c114de9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:31:35 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 14:31:35 +0000 Subject: [issue36511] Add Windows ARM32 buildbot In-Reply-To: <1554232161.58.0.393661272603.issue36511@roundup.psfhosted.org> Message-ID: <1565793095.77.0.291108914598.issue36511@roundup.psfhosted.org> STINNER Victor added the comment: New changeset d85c5670ff1611202a25c9e0967148e72c114de9 by Victor Stinner in branch '3.8': [3.8] bpo-37531: Fix regrtest timeout for subprocesses (GH-15072) (GH-15279) https://github.com/python/cpython/commit/d85c5670ff1611202a25c9e0967148e72c114de9 ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:34:01 2019 From: report at bugs.python.org (Eryk Sun) Date: Wed, 14 Aug 2019 14:34:01 +0000 Subject: [issue37850] Console: holding right arrow key reproduces entire previous input In-Reply-To: <1565780736.93.0.23974280241.issue37850@roundup.psfhosted.org> Message-ID: <1565793241.32.0.753280493072.issue37850@roundup.psfhosted.org> Eryk Sun added the comment: > I did not observe this behaviour on WSL, which is why I think > this is a bug. WSL uses a low-level console interface in virtual-terminal mode. Python's console REPL in Windows is using the standard high-level console editing that's provided by the console host, conhost.exe, when the input mode contains ENABLE_LINE_INPUT | ENABLE_ECHO_INPUT | ENABLE_PROCESSED_INPUT. This includes input history, aliases, and command-line editing that are based on the classic doskey utility from MS-DOS. The UI is documented for NT's doskey.exe command [1], which wraps the console interfaces for command-line history and aliases. Python's built-in REPL could use a low-level console interface like PowerShell does, and implement a readline UI that's consistent with Unix, again like PowerShell has the option to do. Depending on whether we can integrate an existing readline library, that could be a monumental undertaking. pyreadline is a high-level ctypes wrapper that implements this. Last I checked it had some issues with Unicode and wasn't being vigorously maintained, but maybe that's changed. [1] https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/doskey ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:40:10 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Aug 2019 14:40:10 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565793610.43.0.772078484889.issue37831@roundup.psfhosted.org> Guido van Rossum added the comment: It never occurred to me that making b&b an b|b return bool would be considered a bad thing just because ~b is not a bool. That's like complaining that 1+1 returns an int rather than a float for consistency with 1/2 returning a float. Because bool is embedded in int, it's okay to return a bool value *that compares equal to the int from the corresponding int operation*. Code that accepts ints and is passed bools will continue to work. But if we were to make ~b return `not b`, that makes bool not embedded in int (for the sake of numeric operations). Take for example def f(a: int) -> int: return ~a I don't think it's a good idea to make f(0) != f(False). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:44:09 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 14:44:09 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1565793849.62.0.72920999785.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: Thanks Joannah! That's a nice enhancement which should help to stabilize buildbots even more. The next step is bpo-37711: "regrtest: re-run failed tests in subprocesses". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:44:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 14:44:39 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1565793879.97.0.816744421797.issue37531@roundup.psfhosted.org> Change by STINNER Victor : ---------- components: +Tests resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:55:23 2019 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 14 Aug 2019 14:55:23 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565794523.06.0.678904376578.issue37831@roundup.psfhosted.org> Mark Dickinson added the comment: > Because bool is embedded in int, it's okay to return a bool value *that compares equal to the int from the corresponding int operation*. Agreed that it's okay, but I'd like to understand why it's considered *desirable*. What use-cases benefit from having `x | y` give `True` or `False` rather than `1` or `0` when `x` and `y` are bools? Is the intent that `x & y` and `x | y` provide shorter ways to spell `x and y`, `x or y`, or (as I think Serhiy's suggesting) is this about catering to people coming from other languages and expecting `&` and `|` to be the right operations for doing logic with bools? >From my integer-centric point of view, | and & are bitwise integer operations, not logical operations; they only *happen* to apply to bool because a bool is an int, but they're not natural boolean operations (in exactly the same way that +, -, *, etc. aren't natural boolean operations). "and" and "or" seem the "one obvious way to do it" for logical operations on bools; I don't think I understand why anyone would want to use | and & on bools to get another bool, instead of just using `or` and `and`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 10:59:32 2019 From: report at bugs.python.org (Peter Edwards) Date: Wed, 14 Aug 2019 14:59:32 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1565790358.78.0.895060554501.issue21131@roundup.psfhosted.org> Message-ID: Peter Edwards added the comment: On Wed, 14 Aug 2019 at 14:46, STINNER Victor wrote: > > STINNER Victor added the comment: > > "On a 64-bit system, consuming 8M of address space is a drop in the ocean." > > Let me disagree here. Python always allocates faulthandler stack, even if > faulthandler is not used. Even when faulthandler is used, I would prefer to > not waste memory if 8 KiB is good enough. > I can understand the aversion to the waste when its never used - I can address 37851 if you like - it seems pretty simple to fix. The pedant in me must point out that it's 8M of address space, not memory. The cost on 64-bit (well, with a 47-bit user address space) is vanishingly small, regardless of the physical memory on the system. On 32-bit, it's 0.2% of your address space, which I think I'd trade for the safety, but that's your call, and I appreciate that address space can be a constrained resource on 32-bit systems. I do think SIGSTKSZ*2=16k is far too small considering the fault handler could be running arbitrary python code, and we know that there's somewhat less than half of that available for use by the interpreter. > > By the way, I just created bpo-37851 to allocate this stack at the first > faulthandler usage, instead of always allocating it, even when faulthandler > is not used. > > I wrote PR 15276 to use a stack of SIGSTKSZ*2 bytes. According to > msg349694, it does fix the crash. > > Can someone please double check that PR 15276 fix test_faulthandler on a > platform where the test crash without this change? > I can confirm that on the specific hardware I could reproduce this, that PR14276 and setting the stacksize to SIGSTKSZ*2 passes the test_faulthandler test. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 11:21:35 2019 From: report at bugs.python.org (Michael Anckaert) Date: Wed, 14 Aug 2019 15:21:35 +0000 Subject: [issue37823] Telnet documentation: fix the link to open() In-Reply-To: <1565540009.68.0.907395311638.issue37823@roundup.psfhosted.org> Message-ID: <1565796095.99.0.706765415885.issue37823@roundup.psfhosted.org> Change by Michael Anckaert : ---------- keywords: +patch pull_requests: +15005 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15281 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 11:23:17 2019 From: report at bugs.python.org (Michael Anckaert) Date: Wed, 14 Aug 2019 15:23:17 +0000 Subject: [issue37823] Telnet documentation: fix the link to open() In-Reply-To: <1565540009.68.0.907395311638.issue37823@roundup.psfhosted.org> Message-ID: <1565796197.5.0.658628491061.issue37823@roundup.psfhosted.org> Michael Anckaert added the comment: I created a PR for this issue (PR 15281). If any changes are required I'm more than happy to make them. ---------- nosy: +michaelanckaert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 11:40:51 2019 From: report at bugs.python.org (Michael Anckaert) Date: Wed, 14 Aug 2019 15:40:51 +0000 Subject: [issue19820] docs are missing info about module attributes In-Reply-To: <1385620941.03.0.287546381963.issue19820@psf.upfronthosting.co.za> Message-ID: <1565797250.99.0.174526746876.issue19820@roundup.psfhosted.org> Michael Anckaert added the comment: As far as I can tell there is at least some information missing from the 'Types and members' section. Not all attributes are listed in the table. For example the attribute __cached__ is missing from the module type but it is documented in the inspect module. I can update the docs but I would rely on the comments in Lib/inspect.py on what to include. Executing inspect.getmembers on a module returns a lot more attributes than documented in ismodule. ---------- nosy: +michaelanckaert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 11:47:25 2019 From: report at bugs.python.org (David K.) Date: Wed, 14 Aug 2019 15:47:25 +0000 Subject: [issue37845] SLCertVerificationError: Unable to handle SAN names (from Certifications) published with white spaces at start In-Reply-To: <3a325ab0-fcb2-cc66-70b4-9e6a42d3ad61@cheimes.de> Message-ID: David K. added the comment: OK, I see your point :) Modification of the original certificiation is legally problematic. Much thanks for the patience and time to explain, D.K On Wed, Aug 14, 2019, 17:23 Christian Heimes wrote: > > Christian Heimes added the comment: > > On 14/08/2019 15.37, David K. wrote: > > > > David K. added the comment: > > > > Hi, > > > > Judging by your comment, I think there is a an unfortnate > misunderstanding. > > > > If you'd be kind enough, please let me explain: > > > > 1. The issue I had was indeed on Python 3.7, using the highly used > > "requests" library. Also my change was -not- applied on the deprecated > > ssl.match_hostname() > > but on _dnsname_match() which is a method of another inner class. > > My point is that it's still releveant. > > Except it's not revelant any more because that function is no longer > used by CPython's ssl module. Neither match_hostname nor any of its > helper functions are called by code in the ssl module. Since 3.7 all > hostname verification is now performed by OpenSSL code directly. > ssl.match_hostname will be removed in 3.9 or 3.10. > > Latest urllib3 and requests don't use ssl.match_hostname() either. The > urllib3 package has an older copy of the hostname matching algorithm in > urllib3.packages.ssl_match_hostname. It should not be used with modern > Python. > > > 2. Although there is a thin line here, it is not a configuration issue by > > its classic meaning. It's an outside condition in a production > environment > > that unpatches Python code cannot handle and thus implicating that Python > > is less stable and mistake tolerant than C# and Java (those are the other > > more used languages in the company which weren't effected by this problem > > -- for some who wouldn't bother like me to patch python source code, this > > could be a deal breaker to move to another language). > > Your setup has a misconfigured X.509 certificate with a SAN entry that > violates standards for certificates. You are asking me to introduce a > security into Python as a workaround for the misconfiguration. > > The algorithm in match_hostname() and _dnsname_match() implements RFC > 6125, section 6.4.3, in a strict way. Python not only refuses to match > invalid wildcard entries, it also fails hard on RFC 6125 violations. > > > 3. It's a very simple fix that only removes white spaces (empty chars) > from > > start and end of the DNS before applying all the other tests on it. In > fact > > by assuring the input of the DNS name, our code becomes -more- secure. In > > current state, a missed type DNS name encoded in the certifications could > > cause unknowingly Python deamons to stop transmiting data. Also as humans > > tend to make such naive errors, a mallicious party could make an attack > be > > seemless and be discarded as human error. And if that doesn't convince > > you, we can say at the very least the service we provide with our App > > becomes unusable and unavailable to clients and for some that could cost > > time and money and Python may take the blame as unreliable as compared to > > other languages. > > You view the fix as simple and harmless. I see it as a violation of > standards and a security bug. X.509 certs are complex and fragile > beasts. Python have had several CVEs in the hostname matching code > because we didn't implement it correctly. Certificates are also used in > legal contracts, e.g. to legally sign documents or establish mutual > trust. You cannot just modify the content of a certificate. > > Since you are worried about the reliability of Python and started > talking about money, have you considered to donate money to the PSF? > Python is maintained by unpaid volunteers. Donations to the Python > Software Foundation help. (Disclaimer: No money in the world will change > my opinion about "dn.strip()".) > > > 4. The thrown exception can be misleading: The exception says that the > > problem is a partial wildcard. However the problem is white spaces which > > can be difficult to spot. White spaces cannot be part of DNS names thus > it > > makes no sense to ackonwledge them or refer to them or event test them as > > any other legit legal char. Also this is unpredictible to the programmer > as > > he wouldn't think such a basic trim/strip of white spaces wouldn't happen > > in the core of the SSL code what's worse, it can't be handled conventialy > > with catching the exception. While a programmer can edit Python source > code > > to it's needs, they really shouldn't mess with it for more than a short > > term use. Declining the change dooms me for example to always add this > > change to projects using SSL. > > The problem is not the code but the certificate. If you don't care about > valid certificate, then maybe disable hostname / certificate > verification. Or role your own verification. There is no need to modify > any source code for that. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 12:12:41 2019 From: report at bugs.python.org (Michael Anckaert) Date: Wed, 14 Aug 2019 16:12:41 +0000 Subject: [issue1823] Possible to set invalid Content-Transfer-Encoding on email.mime.multipart.MIMEMultipart In-Reply-To: <1200309434.22.0.561367082724.issue1823@psf.upfronthosting.co.za> Message-ID: <1565799161.02.0.72332832101.issue1823@roundup.psfhosted.org> Michael Anckaert added the comment: This issue is still present on Python 3.7 and above. As David suggested set_charset could be turned into a no-op on MIMEMultipart. I traced set_charset back to inheritance from email.message.Message, would overriding set_charset (and possibly raising a deprecation warning) be an acceptable fix? ---------- nosy: +michaelanckaert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 12:35:24 2019 From: report at bugs.python.org (Bennet Fauber) Date: Wed, 14 Aug 2019 16:35:24 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565800524.32.0.26617160203.issue21131@roundup.psfhosted.org> Bennet Fauber added the comment: I updated the versions affected to include 3.6 and 3.7, both of which are affected. I am a bit concerned that the conversation might get fragmented, so I will put in the full URL to the newly created PR at GitHub here. https://github.com/python/cpython/pull/15276 just to make it easier for anyone else who finds this to see where things have gone. I am now, also, uncertain what the current status of https://github.com/python/cpython/pull/13649 is now. It seems that we are now waiting on review from someone from the core developers? ---------- versions: +Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 12:58:36 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Wed, 14 Aug 2019 16:58:36 +0000 Subject: [issue37852] Pickling doesn't work for name-mangled private methods Message-ID: <1565801916.64.0.686845199304.issue37852@roundup.psfhosted.org> New submission from Josh Rosenberg : Inspired by this Stack Overflow question, where it prevented using multiprocessing.Pool.map with a private method: https://stackoverflow.com/q/57497370/364696 The __name__ of a private method remains the unmangled form, even though only the mangled form exists on the class dictionary for lookup. The __reduce__ for bound methods doesn't handle them private names specially, so it will serialize it such that on the other end, it does getattr(method.__self__, method.__func__.__name__). On deserializing, it tries to perform that lookup, but of course, only the mangled name exists, so it dies with an AttributeError. Minimal repro: import pickle class Spam: def __eggs(self): pass def eggs(self): return pickle.dumps(self.__eggs) spam = Spam() pkl = spam.eggs() # Succeeds via implicit mangling (but pickles unmangled name) pickle.loads(pkl) # Fails (tried to load __eggs Explicitly mangling via pickle.dumps(spam._Spam__eggs) fails too, and in the same way. A similar problem occurs (on the serializing end) when you do: pkl = pickle.dumps(Spam._Spam__eggs) # Pickling function in Spam class, not bound method of Spam instance though that failure occurs at serialization time, because pickle itself tries to look up .Spam.__eggs (which doesn't exist), instead of .Spam._Spam__eggs (which does). 1. It fails at serialization time (so it doesn't silently produce pickles that can never be unpickled) 2. It's an explicit PicklingError, with a message that explains what it tried to do, and why it failed ("Can't pickle : attribute lookup Spam.__eggs on __main__ failed") In the use case on Stack Overflow, it was the implicit case; a public method of a class created a multiprocessing.Pool, and tried to call Pool.map with a private method on the same class as the mapper function. While normally pickling methods seems odd, for multiprocessing, it's pretty standard. I think the correct fix here is to make method_reduce in classobject.c (the __reduce__ implementation for bound methods) perform the mangling itself (meth_reduce in methodobject.c has the same bug, but it's less critical, since only private methods of built-in/extension types would be affected, and most of the time, such private methods aren't exposed to Python at all, they're just static methods for direct calling in C). This would handle all bound methods, but for "unbound methods" (read: functions defined in a class), it might also be good to update save_global/get_deep_attribute in _pickle.c to make it recognize the case where a component of a dotted name begins with two underscores (and doesn't end with them), and the prior component is a class, so that pickling the private unbound method (e.g. plain function which happened to be defined on a class) also works, instead of dying with a lookup error. The fix is most important, and least costly, for bound methods, but I think doing it for plain functions is still worthwhile, since I could easily see Pool.map operations using an @staticmethod utility function defined privately in the class for encapsulation purposes, and it seems silly to force them to make it more public and/or remove it from the class. ---------- components: Interpreter Core, Library (Lib) messages: 349716 nosy: josh.r priority: normal severity: normal status: open title: Pickling doesn't work for name-mangled private methods versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:06:16 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 14 Aug 2019 17:06:16 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line In-Reply-To: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> Message-ID: <1565802376.1.0.0701197769311.issue37849@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset 71662dc2f12a7e77e5e1dfe64ec87c1b459c3f59 by Terry Jan Reedy (Tal Einat) in branch 'master': bpo-37849: IDLE: fix completion window positioning above line (GH-15267) https://github.com/python/cpython/commit/71662dc2f12a7e77e5e1dfe64ec87c1b459c3f59 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:06:20 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 17:06:20 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line In-Reply-To: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> Message-ID: <1565802380.86.0.782403589289.issue37849@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15006 pull_request: https://github.com/python/cpython/pull/15282 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:06:27 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 17:06:27 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line In-Reply-To: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> Message-ID: <1565802387.34.0.900069018505.issue37849@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15007 pull_request: https://github.com/python/cpython/pull/15283 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:10:14 2019 From: report at bugs.python.org (Eric Snow) Date: Wed, 14 Aug 2019 17:10:14 +0000 Subject: [issue19820] docs are missing info about module attributes In-Reply-To: <1385620941.03.0.287546381963.issue19820@psf.upfronthosting.co.za> Message-ID: <1565802614.75.0.0299807685506.issue19820@roundup.psfhosted.org> Eric Snow added the comment: The relevant module attributes are described in the importlib docs: https://docs.python.org/3/library/importlib.html#importlib.abc.Loader.load_module ---------- versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:24:07 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 17:24:07 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line In-Reply-To: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> Message-ID: <1565803447.65.0.0815343983486.issue37849@roundup.psfhosted.org> miss-islington added the comment: New changeset 557802dc17498557e481f2ad3d4a83ece469e489 by Miss Islington (bot) in branch '3.8': bpo-37849: IDLE: fix completion window positioning above line (GH-15267) https://github.com/python/cpython/commit/557802dc17498557e481f2ad3d4a83ece469e489 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:35:07 2019 From: report at bugs.python.org (Brad MacGregor) Date: Wed, 14 Aug 2019 17:35:07 +0000 Subject: [issue12178] csv writer doesn't escape escapechar In-Reply-To: <1306348030.98.0.468032848078.issue12178@psf.upfronthosting.co.za> Message-ID: <1565804107.22.0.647645634141.issue12178@roundup.psfhosted.org> Brad MacGregor added the comment: I needed this patch for a project, so I compiled python with the patch applied, and tested my specific use case, and it worked. Thanks for the patch! ---------- nosy: +avatarofhope _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:37:25 2019 From: report at bugs.python.org (Fatih Sarhan) Date: Wed, 14 Aug 2019 17:37:25 +0000 Subject: [issue37853] [urllib.parse.urlparse] It does not correctly parse the URL with basic authentication. Message-ID: <1565804245.33.0.663961239717.issue37853@roundup.psfhosted.org> New submission from Fatih Sarhan : No problem for these: "http://localhost:9100" "http://user:password at localhost:9100" But, these are problematic: "http://use#r:password at localhost:9100" "http://user:pass#word at localhost:9100" ``` from urllib.parse import urlparse url = "http://us#er:123 at localhost:9001/RPC2" u = urlparse(url) print(u) # ParseResult(scheme='http', netloc='us', path='', params='', query='', fragment='er:123 at localhost:9001/RPC2') ``` ---------- components: Library (Lib) messages: 349721 nosy: f9n priority: normal severity: normal status: open title: [urllib.parse.urlparse] It does not correctly parse the URL with basic authentication. type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:37:52 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 17:37:52 +0000 Subject: [issue37849] IDLE: Completion window misplaced when shown above current line In-Reply-To: <1565764849.72.0.621293975284.issue37849@roundup.psfhosted.org> Message-ID: <1565804272.88.0.541556362884.issue37849@roundup.psfhosted.org> miss-islington added the comment: New changeset 88cce7b59fa503616295ca1a25bce6251f9cd317 by Miss Islington (bot) in branch '3.7': bpo-37849: IDLE: fix completion window positioning above line (GH-15267) https://github.com/python/cpython/commit/88cce7b59fa503616295ca1a25bce6251f9cd317 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:42:21 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Aug 2019 17:42:21 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565606932.6.0.360898799273.issue37831@roundup.psfhosted.org> Message-ID: <1565804541.91.0.921807650744.issue37831@roundup.psfhosted.org> Guido van Rossum added the comment: > > Because bool is embedded in int, it's okay to return a bool value *that compares equal to the int from the corresponding int operation*. > Agreed that it's okay, but I'd like to understand why it's considered *desirable*. What use-cases benefit from having `x | y` give `True` or `False` rather than `1` or `0` when `x` and `y` are bools? Is the intent that `x & y` and `x | y` provide shorter ways to spell `x and y`, `x or y`, or (as I think Serhiy's suggesting) is this about catering to people coming from other languages and expecting `&` and `|` to be the right operations for doing logic with bools? > From my integer-centric point of view, | and & are bitwise integer operations, not logical operations; they only *happen* to apply to bool because a bool is an int, but they're not natural boolean operations (in exactly the same way that +, -, *, etc. aren't natural boolean operations). "and" and "or" seem the "one obvious way to do it" for logical operations on bools; I don't think I understand why anyone would want to use | and & on bools to get another bool, instead of just using `or` and `and`. For one thing, you can override `&` and `|` but you can't override `and` and `or`. Probably when we introduced book we should have thought harder about it, but I don't think we should change anything at this point, so I'm not sure why whether it's worth trying to uncover the original deep motivations (probably they weren't so deep). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:45:40 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 14 Aug 2019 17:45:40 +0000 Subject: [issue37831] bool(~True) == True In-Reply-To: <1565804541.91.0.921807650744.issue37831@roundup.psfhosted.org> Message-ID: Guido van Rossum added the comment: s/book/bool/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:46:09 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Wed, 14 Aug 2019 17:46:09 +0000 Subject: [issue37775] update doc of compileall In-Reply-To: <1565113080.48.0.890450145581.issue37775@roundup.psfhosted.org> Message-ID: <1565804769.94.0.871905241364.issue37775@roundup.psfhosted.org> Sanyam Khurana added the comment: I've checked and approved this PR. This needs a core-review now. Thanks, Hai for your contribution. ---------- nosy: +CuriousLearner, Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:49:16 2019 From: report at bugs.python.org (Fatih Sarhan) Date: Wed, 14 Aug 2019 17:49:16 +0000 Subject: [issue37854] [xmlrpc.client.ServerProxy] It does not correctly parse the URL with basic authentication. Message-ID: <1565804956.68.0.411195172232.issue37854@roundup.psfhosted.org> New submission from Fatih Sarhan : Same problem here. (https://bugs.python.org/issue37853) ---------- components: Library (Lib) messages: 349726 nosy: f9n priority: normal severity: normal status: open title: [xmlrpc.client.ServerProxy] It does not correctly parse the URL with basic authentication. versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:55:12 2019 From: report at bugs.python.org (Emmanuel Arias) Date: Wed, 14 Aug 2019 17:55:12 +0000 Subject: [issue19820] docs are missing info about module attributes In-Reply-To: <1385620941.03.0.287546381963.issue19820@psf.upfronthosting.co.za> Message-ID: <1565805312.16.0.264579784197.issue19820@roundup.psfhosted.org> Emmanuel Arias added the comment: > I can update the docs but I would rely on the comments in Lib/inspect.py on what to include. Executing inspect.getmembers on a module returns a lot more attributes than documented in ismodule. I can help too. ---------- nosy: +eamanu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 13:56:58 2019 From: report at bugs.python.org (Fatih Sarhan) Date: Wed, 14 Aug 2019 17:56:58 +0000 Subject: [issue37854] [xmlrpc.client.ServerProxy] It does not correctly parse the URL with basic authentication. In-Reply-To: <1565804956.68.0.411195172232.issue37854@roundup.psfhosted.org> Message-ID: <1565805418.88.0.48657585198.issue37854@roundup.psfhosted.org> Fatih Sarhan added the comment: I just changed things and it works. But it's not right. It must be better way.(The 'urllib.parse.urlparse' function's bug should be fixed. ) https://github.com/f9n/cpython/tree/fix-issue-37854 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 14:00:18 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Wed, 14 Aug 2019 18:00:18 +0000 Subject: [issue37853] [urllib.parse.urlparse] It does not correctly parse the URL with basic authentication. In-Reply-To: <1565804245.33.0.663961239717.issue37853@roundup.psfhosted.org> Message-ID: <1565805618.0.0.517026621876.issue37853@roundup.psfhosted.org> Sanyam Khurana added the comment: Duplicate of Issue 37854 Fatih, Thank you for your report. I'm marking this one as a duplicate of another. Request you to not create multiple issues at once for the same thing. Thank you! ---------- nosy: +CuriousLearner resolution: -> duplicate stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 14:02:17 2019 From: report at bugs.python.org (Sanyam Khurana) Date: Wed, 14 Aug 2019 18:02:17 +0000 Subject: [issue37854] [xmlrpc.client.ServerProxy] It does not correctly parse the URL with basic authentication. In-Reply-To: <1565804956.68.0.411195172232.issue37854@roundup.psfhosted.org> Message-ID: <1565805737.61.0.387541823461.issue37854@roundup.psfhosted.org> Sanyam Khurana added the comment: Closed Issue 37853 as a duplicate. Adding Fatih's comment from there for urllib.parse.urlparse ------------------------------------------------------------- No problem for these: "http://localhost:9100" "http://user:password at localhost:9100" But, these are problematic: "http://use#r:password at localhost:9100" "http://user:pass#word at localhost:9100" ``` from urllib.parse import urlparse url = "http://us#er:123 at localhost:9001/RPC2" u = urlparse(url) print(u) # ParseResult(scheme='http', netloc='us', path='', params='', query='', fragment='er:123 at localhost:9001/RPC2') ``` -------------------------------------- ---------- nosy: +CuriousLearner versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 14:07:20 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 14 Aug 2019 18:07:20 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565806040.67.0.184627967312.issue29535@roundup.psfhosted.org> Ashwin Ramaswami added the comment: Why is it ok for certain hashes (such as tuples) to be not non-deterministic, while other hashes (such as datetime) need to be non-deterministic? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 14:26:30 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 14 Aug 2019 18:26:30 +0000 Subject: [issue37848] More fully implement Unicode's case mappings In-Reply-To: <1565761340.97.0.731805225537.issue37848@roundup.psfhosted.org> Message-ID: <1565807190.59.0.0807605011381.issue37848@roundup.psfhosted.org> Greg Price added the comment: > I believe that all locale specific things should be in the locale module, not in the str class. The locale module is all about doing things with the current process-global Unix locale. I don't think that'd be an appropriate interface for this -- if it's worth doing, it's worth doing in such a way that the same web server process can handle requests for Turkish-, Lithuanian-, and Spanish-speaking users without having to reset a global variable for each one. > If a locale specific mapping is requested, this should be done > explicitly by e.g. providing a parameter to str.lower() / upper() / > title(). I like this design. I said "locale" above, but that wasn't quite right, I think -- the file says e.g. `tr`, not `tr_TR` and `tr_CY`, and it describes the identifiers as "language IDs". So perhaps str.lower(*, lang=None) ? And then "I".lower(lang="tr") == "?" == "\N{Latin small letter dotless I}" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 14:32:20 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 14 Aug 2019 18:32:20 +0000 Subject: [issue37852] Pickling doesn't work for name-mangled private methods In-Reply-To: <1565801916.64.0.686845199304.issue37852@roundup.psfhosted.org> Message-ID: <1565807540.57.0.0401409144392.issue37852@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 14:40:35 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 14 Aug 2019 18:40:35 +0000 Subject: [issue37848] More fully implement Unicode's case mappings In-Reply-To: <1565761340.97.0.731805225537.issue37848@roundup.psfhosted.org> Message-ID: <1565808035.81.0.883951007538.issue37848@roundup.psfhosted.org> Greg Price added the comment: > Maintaining Python is already expensive [...] There are already enough bugs waiting for you to be fixed ;-) BTW I basically agree with this. I think this is not a high-priority issue, and I have my eye on some of those bugs. :-) I think the fact that it's per-*language* (despite my inaccurate phrasing in the OP), not per-locale, simplifies it some -- for example the whole `.UTF-8` vs `.utf8` thing doesn't appear. And in particular I think if/when someone decides to sit down and make an implementation of this, then if they take the time to carefully read and absorb the relevant pages of the standard... this is a feature where it's pretty feasible for the implementation to be a self-contained and relatively stable and low-bugs piece of code. And in general I think even if nobody implements it soon, it's useful to have an issue that can be pointed to for this feature, and especially so if the discussion clearly lays out what the feature involves and what different people's views are on the API. For example #18236 has been open for 6 years, but the discussion there was extremely helpful for me to understand it and work up a fix, after just being pointed to it by someone who'd searched the tracker on seeing me send in the doc fix GH-15019. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 14:48:14 2019 From: report at bugs.python.org (Zhiyong Zhang) Date: Wed, 14 Aug 2019 18:48:14 +0000 Subject: [issue37855] Compiling Python 3.7.4 with Intel compilers 2019 Message-ID: <1565808494.42.0.743401642234.issue37855@roundup.psfhosted.org> New submission from Zhiyong Zhang : Compilation of Python 3.7.4 with Intel icc/2019 failed with the following errors: icpc -c -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -g -O0 -Wall -O3 -fp-model strict -fp-model source -xHost -ipo -prec-div -prec-sqrt -std=c++11 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fp-model strict -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fp-model strict -IObjects -IInclude -IPython -I. -I../Include -DPy_BUILD_CORE -o Programs/python.o ../Programs/python.c In file included from ../Include/Python.h(75), from ../Programs/python.c(3): ../Include/pyatomic.h(32): error: identifier "memory_order_relaxed" is undefined _Py_memory_order_relaxed = memory_order_relaxed, ^ In file included from ../Include/Python.h(75), from ../Programs/python.c(3): ../Include/pyatomic.h(33): error: identifier "memory_order_acquire" is undefined _Py_memory_order_acquire = memory_order_acquire, ^ In file included from ../Include/Python.h(75), from ../Programs/python.c(3): ../Include/pyatomic.h(34): error: identifier "memory_order_release" is undefined _Py_memory_order_release = memory_order_release, ^ In file included from ../Include/Python.h(75), from ../Programs/python.c(3): ../Include/pyatomic.h(35): error: identifier "memory_order_acq_rel" is undefined _Py_memory_order_acq_rel = memory_order_acq_rel, ^ In file included from ../Include/Python.h(75), from ../Programs/python.c(3): ../Include/pyatomic.h(36): error: identifier "memory_order_seq_cst" is undefined _Py_memory_order_seq_cst = memory_order_seq_cst ^ In file included from ../Include/Python.h(75), from ../Programs/python.c(3): ../Include/pyatomic.h(40): error: identifier "atomic_uintptr_t" is undefined atomic_uintptr_t _value; ^ In file included from ../Include/Python.h(75), from ../Programs/python.c(3): ../Include/pyatomic.h(44): error: identifier "atomic_int" is undefined atomic_int _value; ^ ---------- components: Installation messages: 349734 nosy: zyzhang2006 priority: normal severity: normal status: open title: Compiling Python 3.7.4 with Intel compilers 2019 type: compile error versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 15:00:03 2019 From: report at bugs.python.org (Michael Anckaert) Date: Wed, 14 Aug 2019 19:00:03 +0000 Subject: [issue19820] docs are missing info about module attributes In-Reply-To: <1385620941.03.0.287546381963.issue19820@psf.upfronthosting.co.za> Message-ID: <1565809203.74.0.183340608147.issue19820@roundup.psfhosted.org> Michael Anckaert added the comment: @emmanuel: thanks for offering your help. I made a first attempt at improving the docs in this branch: https://github.com/MichaelAnckaert/cpython/tree/bpo-19820 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 15:03:38 2019 From: report at bugs.python.org (reimar) Date: Wed, 14 Aug 2019 19:03:38 +0000 Subject: [issue36753] Python modules not linking to libpython causes issues for RTLD_LOCAL system-wide In-Reply-To: <1556554560.81.0.844742203447.issue36753@roundup.psfhosted.org> Message-ID: <1565809418.03.0.581029095376.issue36753@roundup.psfhosted.org> reimar added the comment: I'm not sure how I can explain it much better, I even wrote example code after all, but I'll try... > So if you are embedding python by dlopen'ing libpython.so Neither me nor Laszlo are using/embedding or otherwise involving Python (directly/intentionally at least). We just want to load some .so file. That .so itself might then use libpython. Or use a library that uses libpython. Or uses a library that uses a library .... that uses libpython. And how could we know whether SOME library down that dependency chain uses libpython or not? The result is that now EVERY SINGLE LIBRARY IN THE WHOLE SYSTEM needs to be loaded with RTLD_GLOBAL. Because a library 50 dependencies down that uses python might break otherwise and there's not really any way to know. Just to try be very clear: We are not users of libpython, we do not write or use any python code ourselves (except through indirect dependencies) and we are still hit by this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 15:08:26 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 14 Aug 2019 19:08:26 +0000 Subject: [issue37833] tkinter crashes macOS in the latest macOS update 10.14.6 In-Reply-To: <1565618378.34.0.81940050082.issue37833@roundup.psfhosted.org> Message-ID: <1565809706.95.0.16361688371.issue37833@roundup.psfhosted.org> Ronald Oussoren added the comment: The py2app issue I mentioned is not relevant for this issue. A simple tkinter runs fine with Python 3.7 (64-bit, 3.7.4, Python.org installer), the same script causes a WindowServer crash (SEGV) when bundled with py2app. This is definitely a bug in macOS, the WindowServer should not crash like this even if an app is misbehaving. I'm therefore changing the status of this issue to closed/third party. ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 15:09:19 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 14 Aug 2019 19:09:19 +0000 Subject: [issue37848] More fully implement Unicode's case mappings In-Reply-To: <1565761340.97.0.731805225537.issue37848@roundup.psfhosted.org> Message-ID: <1565809759.52.0.219118804368.issue37848@roundup.psfhosted.org> Greg Price added the comment: (I should add that it was only after doing the reading that produced the OP that I had a clear idea what I thought the priority of the issue was -- before doing that work I didn't have a clear sense of the scope of what it affects. Based on that SpecialCasing.txt file as of Unicode 12.0.0, I believe the functionality we don't currently support is entirely about the handling of certain versions of the Latin letter I, as treated in Lithuanian, Turkish, and Azerbaijani. Though one function of this issue thread is that it would be a great place to point out if there's another component to it!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 15:11:06 2019 From: report at bugs.python.org (reimar) Date: Wed, 14 Aug 2019 19:11:06 +0000 Subject: [issue36753] Python modules not linking to libpython causes issues for RTLD_LOCAL system-wide In-Reply-To: <1556554560.81.0.844742203447.issue36753@roundup.psfhosted.org> Message-ID: <1565809866.31.0.451557593469.issue36753@roundup.psfhosted.org> reimar added the comment: I guess one way this could be "solved" would be by libpython doing a dlopen on itself with RTLD_GLOBAL on Python initialization. I wouldn't bet that that wouldn't end up with some very interesting unintended consequences as well though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 15:39:17 2019 From: report at bugs.python.org (evanTO) Date: Wed, 14 Aug 2019 19:39:17 +0000 Subject: [issue37856] Adding additional python installations to py launcher Message-ID: <1565811557.54.0.422004539892.issue37856@roundup.psfhosted.org> New submission from evanTO : I have four instances of Python installed on my machine, 2.7x32 & 3.7x32 that I installed manually into their default locations, and 2.7x64 & 3.4x64 that came pre-packaged with a third party piece of software (SPSS). Py Launcher successfully detects the two installations that I installed manually but cannot see the two installations that came with the third party software. Here (https://www.python.org/dev/peps/pep-0397/#configuration-file) there is an allusion to there being commands which allow customization of Py launcher within user space (monkeying around with the registry in a corporate environments is often disallowed). I have created a py.ini file using the [commands] section with respective copies of the following entry: "3.4-64="C:\Program Files\IBM\SPSS\Statistics\24\Python3\python.exe" and saved to "C:\Users\\AppData\Local" but the additional installations do not appear. I have added the two additional installation directories (and Scripts folders) to the PATH variable and confirmed that the changes persisted (displayed below): PATH=C:\Program Files (x86)\Python37-32\Scripts\;C:\Program Files (x86)\Python37-32\;C:\Python27\;C:\Python27\Scripts;C:\Program Files\IBM\SPSS\Statistics\24\Python\;C:\Program Files\IBM\SPSS\Statistics\24\Python\Scripts\;C:\Program Files\IBM\SPSS\Statistics\24\Python3\;C:\Program Files\IBM\SPSS\Statistics\24\Python3\Scripts\; Current result of "py -0p" (List the available pythons with paths) C:\>py -0p Installed Pythons found by py Launcher for Windows -3.7-32 "C:\Program Files (x86)\Python37-32\python.exe" * -2.7-32 C:\Python27\python.exe Expected result of "py -0p" C:\>py -0p Installed Pythons found by py Launcher for Windows -3.7-32 "C:\Program Files (x86)\Python37-32\python.exe" * -2.7-32 C:\Python27\python.exe -3.4-64 "C:\Program Files\IBM\SPSS\Statistics\24\Python3\python.exe" -2.7-64 "C:\Program Files\IBM\SPSS\Statistics\24\Python\python.exe" ---------- components: Windows messages: 349740 nosy: evanTO, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Adding additional python installations to py launcher type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 15:46:10 2019 From: report at bugs.python.org (Zane Bitter) Date: Wed, 14 Aug 2019 19:46:10 +0000 Subject: [issue37857] Setting logger.level directly has no effect due to caching in 3.7+ Message-ID: <1565811970.47.0.529067236549.issue37857@roundup.psfhosted.org> New submission from Zane Bitter : This is a related issue to bug 34269, in the sense that it is also due to the caching added by the fix for bug 30962. In this case, the bug is triggered by setting the public 'level' attribute of a logging.Logger object, instead of calling the setLevel() method. Although this was probably never a good idea, prior to Python3.7 it worked as expected. Now it renders the level out of sync with the cache, leading to inconsistent results that are hard to debug. An example in the wild: https://review.opendev.org/676450 ---------- components: Library (Lib) messages: 349741 nosy: zaneb priority: normal severity: normal status: open title: Setting logger.level directly has no effect due to caching in 3.7+ type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 15:52:49 2019 From: report at bugs.python.org (SilentGhost) Date: Wed, 14 Aug 2019 19:52:49 +0000 Subject: [issue37857] Setting logger.level directly has no effect due to caching in 3.7+ In-Reply-To: <1565811970.47.0.529067236549.issue37857@roundup.psfhosted.org> Message-ID: <1565812369.83.0.142667042546.issue37857@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 15:55:48 2019 From: report at bugs.python.org (Zane Bitter) Date: Wed, 14 Aug 2019 19:55:48 +0000 Subject: [issue30962] Add caching to logging.Logger.isEnabledFor() In-Reply-To: <1500409493.45.0.605739415496.issue30962@psf.upfronthosting.co.za> Message-ID: <1565812548.15.0.322389603598.issue30962@roundup.psfhosted.org> Change by Zane Bitter : ---------- pull_requests: +15009 pull_request: https://github.com/python/cpython/pull/15286 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 15:55:48 2019 From: report at bugs.python.org (Zane Bitter) Date: Wed, 14 Aug 2019 19:55:48 +0000 Subject: [issue37857] Setting logger.level directly has no effect due to caching in 3.7+ In-Reply-To: <1565811970.47.0.529067236549.issue37857@roundup.psfhosted.org> Message-ID: <1565812548.08.0.874800801205.issue37857@roundup.psfhosted.org> Change by Zane Bitter : ---------- keywords: +patch pull_requests: +15008 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15286 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 16:02:32 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 14 Aug 2019 20:02:32 +0000 Subject: [issue35214] Get the test suite passing with clang Memory Sanitizer enabled In-Reply-To: <1542007595.0.0.788709270274.issue35214@psf.upfronthosting.co.za> Message-ID: <1565812952.64.0.525558400347.issue35214@roundup.psfhosted.org> Gregory P. Smith added the comment: Nope, work remains to be done. I've got an msan buildbot system waiting but haven't had time to follow up on figuring out what remains in a while. (getting a functioning memory sanitizer build is... finnicky to say the least) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 16:07:11 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 14 Aug 2019 20:07:11 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1565813231.67.0.133846798962.issue9949@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +patch pull_requests: +15011 pull_request: https://github.com/python/cpython/pull/15287 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 16:14:54 2019 From: report at bugs.python.org (Ashley Harvey) Date: Wed, 14 Aug 2019 20:14:54 +0000 Subject: [issue37858] CookieLib: MozillaCookieJar.py uses case-sensitive regex to validate cookies file Message-ID: <1565813694.91.0.343923131881.issue37858@roundup.psfhosted.org> New submission from Ashley Harvey : I'm on macOS 10.14.6, wget 1.20.3, python 2.7. Command line: $ wget --save-cookies cookies.txt --keep-session-cookies --post-data 'username=myUserName&password=myPassword' --delete-after Line 39 of _MozillaCookieJar.py (cookielib) shows it looking for 'magic_re = "#( Netscape)? HTTP Cookie File"' in order to validate the supplied cookies file. Unlike cURL, wget however, produces a cookies file that begins with "# HTTP cookie file". Note the lower-case c and f. I reported this as a bug to the wget team who looked for the spec to say that that line must follow a certain format and couldn't find any such mention. (See: https://savannah.gnu.org/bugs/?56755) The lack of upper-case c and f cause cookielib to choke and stop processing the cookies file, and so here I am reporting it as a bug that the regex is case-sensitive. ---------- components: Library (Lib), macOS messages: 349743 nosy: ashleyharvey, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: CookieLib: MozillaCookieJar.py uses case-sensitive regex to validate cookies file type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 16:21:48 2019 From: report at bugs.python.org (Ned Deily) Date: Wed, 14 Aug 2019 20:21:48 +0000 Subject: [issue37858] CookieLib: MozillaCookieJar.py uses case-sensitive regex to validate cookies file In-Reply-To: <1565813694.91.0.343923131881.issue37858@roundup.psfhosted.org> Message-ID: <1565814108.45.0.268834871997.issue37858@roundup.psfhosted.org> Ned Deily added the comment: (removing the macOS component since presumably this behavior is not platform-dependent) ---------- components: -macOS nosy: -ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 16:22:14 2019 From: report at bugs.python.org (Ned Deily) Date: Wed, 14 Aug 2019 20:22:14 +0000 Subject: [issue37858] CookieLib: MozillaCookieJar.py uses case-sensitive regex to validate cookies file In-Reply-To: <1565813694.91.0.343923131881.issue37858@roundup.psfhosted.org> Message-ID: <1565814134.53.0.576114909113.issue37858@roundup.psfhosted.org> Change by Ned Deily : ---------- nosy: -ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 16:32:41 2019 From: report at bugs.python.org (Red Glyph) Date: Wed, 14 Aug 2019 20:32:41 +0000 Subject: [issue37859] time.process_time() constant / erratic on Windows Message-ID: <1565814761.83.0.783590608069.issue37859@roundup.psfhosted.org> New submission from Red Glyph : Tested with - Python 3.7.4, 64-bit, Windows version (installer version) - python-3.8.0b3-embed-amd64.zip - python-3.7.2.post1-embed-amd64.zip on Windows 7 x64 Professional time.process_time() always returns the same value. If I check the value of time.process_time_ns(), sometimes it is constant, sometimes I observe a few changes, then it becomes constant too. Here is a log of an example session, I'm waiting at least 1-2 seconds between each command: Python 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license()" for more information. >>> import time >>> time.process_time() 0.1092007 >>> time.process_time() 0.1092007 >>> time.process_time_ns() 109200700 >>> time.process_time_ns() 124800800 >>> time.process_time_ns() 124800800 >>> time.process_time() 0.1248008 >>> time.process_time() 0.1248008 >>> time.process_time() 0.1248008 >>> time.process_time_ns() 124800800 >>> time.process_time_ns() 124800800 >>> time.process_time_ns() 124800800 >>> time.process_time_ns() 124800800 >>> time.clock() Warning (from warnings module): File "__main__", line 1 DeprecationWarning: time.clock has been deprecated in Python 3.3 and will be removed from Python 3.8: use time.perf_counter or time.process_time instead 77.006126126 >>> time.clock() 79.245575778 >>> time.clock() 80.801103036 >>> time.process_time() 0.1248008 >>> ---------- components: Library (Lib), Windows messages: 349745 nosy: Red Glyph, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: time.process_time() constant / erratic on Windows type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 16:44:24 2019 From: report at bugs.python.org (Red Glyph) Date: Wed, 14 Aug 2019 20:44:24 +0000 Subject: [issue37859] time.process_time() constant / erratic on Windows In-Reply-To: <1565814761.83.0.783590608069.issue37859@roundup.psfhosted.org> Message-ID: <1565815464.75.0.453012527694.issue37859@roundup.psfhosted.org> Change by Red Glyph : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 16:47:45 2019 From: report at bugs.python.org (Zachary Ware) Date: Wed, 14 Aug 2019 20:47:45 +0000 Subject: [issue37859] time.process_time() constant / erratic on Windows In-Reply-To: <1565814761.83.0.783590608069.issue37859@roundup.psfhosted.org> Message-ID: <1565815665.05.0.858493151151.issue37859@roundup.psfhosted.org> Zachary Ware added the comment: Try this: while time.process_time() < 0.5: print('.', flush=True, end='') Or: >>> time.process_time() 0.03125 >>> len(str(2**500_000)) 150515 >>> time.process_time() 0.484375 Basically, process_time() (and process_time_ns()) measure CPU time used by the process, and you aren't making the CPU do anything between your checks. ---------- resolution: not a bug -> stage: resolved -> status: closed -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 16:48:14 2019 From: report at bugs.python.org (Zachary Ware) Date: Wed, 14 Aug 2019 20:48:14 +0000 Subject: [issue37859] time.process_time() constant / erratic on Windows In-Reply-To: <1565814761.83.0.783590608069.issue37859@roundup.psfhosted.org> Message-ID: <1565815694.85.0.324500387645.issue37859@roundup.psfhosted.org> Change by Zachary Ware : ---------- resolution: -> not a bug stage: -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 16:52:59 2019 From: report at bugs.python.org (Eryk Sun) Date: Wed, 14 Aug 2019 20:52:59 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565815979.12.0.939517533917.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > I really want a fix for this in 3.8, or else os.stat(sys.executable) > may fail I agree, but Python can support this without handling junctions as symlinks or limiting the reparse points that we can follow. There are reparse points for offline storage and projected file systems (e.g. VFS for Git) that should normally be traversed, and to that I would add junctions. stat() in Unix always opens a mounted directory, not the underlying directory of a mount point. Windows Python should try to be consistent with Unix where doing so is reasonable. Given the only option here is follow_symlinks, then the first CreateFileW call in win32_xstat_impl should only open a reparse point if follow_symlinks is false. In this case, if it happens to open a reparse point that's not a symlink, it should try to reopen with reparsing enabled. In either case, if reparsing fails because a reparse point isn't handled (ERROR_CANT_ACCESS_FILE), try to open the reparse point itself. The latter would be the second open attempt if follow_symlinks is true and the third open attempt if follow_symlinks is false. If a reparse point isn't handled, then there's nothing in principle that stat() could ever follow. Given that it's impractical to fail in this case, considering how much code would have to be modified, then the above compromise should suffice. I checked RtlNtStatusToDosError over the range 0xC000_0000 - 0xC0ED_FFFF. (In ntstatus.h, FACILITY_MAXIMUM_VALUE is 0xED, so there's no point in checking facilities 0x0EF-0xFFF.) Only STATUS_IO_REPARSE_TAG_NOT_HANDLED maps to ERROR_CANT_ACCESS_FILE, so we don't have to worry about unrelated failures using this error code. This is separate from an invalid reparse point (ERROR_INVALID_REPARSE_DATA) or a reparse point that can't be resolved (ERROR_CANT_RESOLVE_FILENAME), which should still be errors that fail the call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 16:59:13 2019 From: report at bugs.python.org (Red Glyph) Date: Wed, 14 Aug 2019 20:59:13 +0000 Subject: [issue37859] time.process_time() constant / erratic on Windows In-Reply-To: <1565814761.83.0.783590608069.issue37859@roundup.psfhosted.org> Message-ID: <1565816353.12.0.280789663393.issue37859@roundup.psfhosted.org> Red Glyph added the comment: I see that now. The behaviour was different in Linux, though, I suppose it may benefit from a more precise counter, but since in Windows it also has a precise counter with time.perf_counter_ns(), I was expecting to see that value change, but it was mainly a confusion with the older time.clock(). Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:00:53 2019 From: report at bugs.python.org (Eryk Sun) Date: Wed, 14 Aug 2019 21:00:53 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565816453.06.0.766901071197.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > but suddenly adding "\\?\" to the paths breaks a lot of assumptions. The unwritten assumption has been that readlink() is reading symlinks that get created by CreateSymbolicLinkW, which sets the print name as the DOS path that's passed to the call. In this case, readlink() can rely on the print name being the intended DOS path. I raised a concern in the case of reading junctions. There's no high-level API to create junctions, so we can't assume the print name is reliable. PowerShell's new-item doesn't even set a print name for junctions. That symlinks also are valid without a print name (in principle; I haven't come across it practice) lends additional weight to always using the substitute name. Even if we have the DOS path, resolving paths manually is still complicated if it's a relative symlink with a reserved name (DOS device; trailing dots or spaces) as the final component or if it's a long path. Reparsing a relative symlink in the kernel doesn't reserve such names and there's no MAX_PATH limit in the kernel. So using readlink() is tricky. Fortunately realpath() in Windows doesn't require a resolve loop based on readlink(). The kernel almost always knows the final path of an opened file, and we can walk the components from the end until we find one that exists. > My idea was to GetFinalPathName(path[4:])[4:] and if that fails An existing file named "spam" would be a false positive for a link that targets "spam.". The internal CreateFileW call would open "spam". Also, symlinks allow remote paths, and this doesn't handle "\\\\?\\UNC" paths. More generally, a link target doesn't have to exist, so being able to access it shouldn't be a factor. I see it's also returning the result from _getfinalpathname. readlink() doesn't resolve a final, solid path. It just returns the contents of a link, which can be a relative or absolute path. In the proposed implementation of realpath() that I helped on for issue 14094 (I wasn't aware of the previous work in issue 9949), there's an _extended_to_normal function that tries to return a normal path if possible. The length of the normal path has to be less than MAX_PATH, and _getfullpathname should return the path unchanged. GetFullPathNameW is just rule-based processing in user mode; it doesn't touch the file system. I wish we could remove the MAX_PATH limit in this case. I think at startup we should try to call RtlAreLongPathsEnabled, even though it's not documented, and set a sys flag to indicate whether we can use long paths. Also, support a -X option and an environment variable to override automatic detection. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:04:49 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 14 Aug 2019 21:04:49 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565816689.65.0.779354094457.issue29535@roundup.psfhosted.org> Christian Heimes added the comment: PEP 456 explains why hash of str and bytes must be randomized. I don't know any reason why hash of datetime objects must be randomized. They can be deterministic like floats and ints. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:11:36 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 21:11:36 +0000 Subject: [issue37826] Document PEP 3134 in tutorials/errors.rst In-Reply-To: <1565548566.46.0.213467869715.issue37826@roundup.psfhosted.org> Message-ID: <1565817096.29.0.763853088135.issue37826@roundup.psfhosted.org> miss-islington added the comment: New changeset dcfe111eb5602333135b8776996332a8dcf59392 by Miss Islington (bot) (Abhilash Raj) in branch 'master': bpo-37826: Document exception chaining in Python tutorial for errors. (GH-15243) https://github.com/python/cpython/commit/dcfe111eb5602333135b8776996332a8dcf59392 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:14:46 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 14 Aug 2019 21:14:46 +0000 Subject: [issue37860] Add netlify deploy preview for docs Message-ID: <1565817286.53.0.142673590989.issue37860@roundup.psfhosted.org> New submission from Ashwin Ramaswami : It would be good to preview the cpython documentation on PRs using Netlify. See https://github.com/python/core-workflow/issues/348 ---------- assignee: docs at python components: Documentation messages: 349752 nosy: docs at python, epicfaace priority: normal severity: normal status: open title: Add netlify deploy preview for docs versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:15:03 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 14 Aug 2019 21:15:03 +0000 Subject: [issue37860] Add netlify deploy preview for docs In-Reply-To: <1565817286.53.0.142673590989.issue37860@roundup.psfhosted.org> Message-ID: <1565817303.81.0.717610997107.issue37860@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- nosy: +Mariatta _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:16:18 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 14 Aug 2019 21:16:18 +0000 Subject: [issue37860] Add netlify deploy preview for docs In-Reply-To: <1565817286.53.0.142673590989.issue37860@roundup.psfhosted.org> Message-ID: <1565817378.92.0.178107044705.issue37860@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- keywords: +patch pull_requests: +15012 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15288 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:18:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 21:18:25 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) In-Reply-To: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> Message-ID: <1565817505.34.0.0254942074255.issue37811@roundup.psfhosted.org> STINNER Victor added the comment: > See Also: #31334 Oh, I didn't know bpo-31334. This issue is basically a duplicate of bpo-31334, but triggered differently. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:21:52 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 21:21:52 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) In-Reply-To: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> Message-ID: <1565817712.04.0.901377284054.issue37811@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 28146206578ebe1b84b48e6f255738a227058c04 by Victor Stinner (Artem Khramov) in branch 'master': bpo-37811: FreeBSD, OSX: fix poll(2) usage in sockets module (GH-15202) https://github.com/python/cpython/commit/28146206578ebe1b84b48e6f255738a227058c04 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:22:15 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 21:22:15 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) In-Reply-To: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> Message-ID: <1565817735.65.0.154927616322.issue37811@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15013 pull_request: https://github.com/python/cpython/pull/15289 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:22:21 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 21:22:21 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) In-Reply-To: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> Message-ID: <1565817741.69.0.38594902052.issue37811@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15014 pull_request: https://github.com/python/cpython/pull/15290 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:32:54 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 21:32:54 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565818374.03.0.188467063522.issue21131@roundup.psfhosted.org> STINNER Victor added the comment: "I do think SIGSTKSZ*2=16k is far too small considering the fault handler could be running arbitrary python code," We are talking abou the faulthandler_user() function of Modules/faulthandler.c. It is implemented in pure C, it doesn't allocate memory on the heap, it uses a very small set of functions (write(), sigaction(), raise()) and it tries to minimize its usage of the stack memory. It is very different than the traceback module which is implemented in pure Python. faulthandler is really designed to debug segmentation fault, stack overflow, Python hang (like a deadlock), etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:34:42 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 21:34:42 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565818482.98.0.514854901469.issue21131@roundup.psfhosted.org> STINNER Victor added the comment: "I can understand the aversion to the waste when its never used - I can address 37851 if you like - it seems pretty simple to fix. The pedant in me must point out that it's 8M of address space, not memory. The cost on 64-bit (well, with a 47-bit user address space) is vanishingly small, ..." Well, many users pay attention to the RSS value and don't care if the memory is physically allocated or not. Moreover, I'm not sure that we can fix bpo-37851 in Python 3.7. In general, the policy is to minimize changes in stable Python versions. I'm not sure for Python 3.8 neither. I would suggest to only modify Python 3.9, simply to reduce the risk of regressions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:35:30 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 21:35:30 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565818530.61.0.797752776674.issue21131@roundup.psfhosted.org> STINNER Victor added the comment: New changeset ac827edc493d3ac3f5b9b0cc353df1d4b418a9aa by Victor Stinner in branch 'master': bpo-21131: Fix faulthandler.register(chain=True) stack (GH-15276) https://github.com/python/cpython/commit/ac827edc493d3ac3f5b9b0cc353df1d4b418a9aa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:35:38 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 21:35:38 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565818538.75.0.88012601986.issue21131@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15015 pull_request: https://github.com/python/cpython/pull/15291 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:35:45 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 21:35:45 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565818545.03.0.964676671253.issue21131@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15016 pull_request: https://github.com/python/cpython/pull/15292 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:38:18 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 14 Aug 2019 21:38:18 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565818698.03.0.14238099541.issue37834@roundup.psfhosted.org> Steve Dower added the comment: > Given the only option here is follow_symlinks, then the first CreateFileW call in win32_xstat_impl should only open a reparse point if follow_symlinks is false. In this case, if it happens to open a reparse point that's not a symlink, it should try to reopen with reparsing enabled. In either case, if reparsing fails because a reparse point isn't handled (ERROR_CANT_ACCESS_FILE), try to open the reparse point itself. The latter would be the second open attempt if follow_symlinks is true and the third open attempt if follow_symlinks is false. > > If a reparse point isn't handled, then there's nothing in principle that stat() could ever follow. Given that it's impractical to fail in this case, considering how much code would have to be modified, then the above compromise should suffice. This sounds like reasonable logic. I'll take a look at updating my PR. > In the proposed implementation of realpath() that I helped on for issue 14094 I totally forgot about this issue and the PR (but it looks like the contributor did too). I just posted PR 15287 today with the tests from the patch on issue9949 and it's looking okay - certainly an improvement over the current behaviour. But it doesn't have the change to readlink() that would add the \\?\ prefix, which means it doesn't answer that question. > I wish we could remove the MAX_PATH limit in this case. The problem is that we have to remove the limit in any case where the resulting path might be used, which is what we're already trying to encourage by supporting long paths. Perhaps the best we can do is an additional test where we GetFinalPathName, strip the prefix, reopen the file, GetFinalPathName again and if they match then return it without the prefix. That should handle the both long path settings as transparently as we can. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:45:26 2019 From: report at bugs.python.org (Eryk Sun) Date: Wed, 14 Aug 2019 21:45:26 +0000 Subject: [issue37859] time.process_time() constant / erratic on Windows In-Reply-To: <1565814761.83.0.783590608069.issue37859@roundup.psfhosted.org> Message-ID: <1565819126.89.0.00196746257002.issue37859@roundup.psfhosted.org> Eryk Sun added the comment: > I suppose it may benefit from a more precise counter, but since in > Windows it also has a precise counter with time.perf_counter_ns(), > I was expecting to see that value change, but it was mainly a > confusion with the older time.clock(). Don't read too much into the clock info here: >>> time.get_clock_info('process_time').resolution 1e-07 Process times [1] are stored as a 64-bit integer in units of 100 ns (1e-7). But the kernel schedules threads based on a timer that ticks every 15.625 ms by default. It can be lowered to about 0.5 ms, but this degrades battery life. [1] https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getprocesstimes ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:47:49 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 21:47:49 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) In-Reply-To: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> Message-ID: <1565819269.93.0.76821651637.issue37811@roundup.psfhosted.org> miss-islington added the comment: New changeset 123f6c4914827c4ced65d032fab74de62db31cd6 by Miss Islington (bot) in branch '3.8': bpo-37811: FreeBSD, OSX: fix poll(2) usage in sockets module (GH-15202) https://github.com/python/cpython/commit/123f6c4914827c4ced65d032fab74de62db31cd6 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:48:07 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 21:48:07 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) In-Reply-To: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> Message-ID: <1565819287.78.0.856129595606.issue37811@roundup.psfhosted.org> miss-islington added the comment: New changeset b0b178a2b80974da910ce6a344d66cc4d9a2fcfa by Miss Islington (bot) in branch '3.7': bpo-37811: FreeBSD, OSX: fix poll(2) usage in sockets module (GH-15202) https://github.com/python/cpython/commit/b0b178a2b80974da910ce6a344d66cc4d9a2fcfa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:49:29 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 21:49:29 +0000 Subject: [issue37859] time.process_time() constant / erratic on Windows In-Reply-To: <1565814761.83.0.783590608069.issue37859@roundup.psfhosted.org> Message-ID: <1565819369.87.0.549642834661.issue37859@roundup.psfhosted.org> STINNER Victor added the comment: > Process times [1] are stored as a 64-bit integer in units of 100 ns (1e-7). But the kernel schedules threads based on a timer that ticks every 15.625 ms by default. It can be lowered to about 0.5 ms, but this degrades battery life. Patches are welcome to enhance time.get_clock_info() :-) Don't rely too much on time.get_clock_info() on Linux neither: it basically always say 1 ns, even if the effective resolution is way worse. See the PEP 418 for some numbers: https://www.python.org/dev/peps/pep-0418/#process-time I wrote these programs to write this PEP ;-) https://github.com/python/peps/tree/master/pep-0418 ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 17:54:45 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 21:54:45 +0000 Subject: [issue37859] time.process_time() constant / erratic on Windows In-Reply-To: <1565814761.83.0.783590608069.issue37859@roundup.psfhosted.org> Message-ID: <1565819685.05.0.341518261044.issue37859@roundup.psfhosted.org> STINNER Victor added the comment: > I see that now. The behaviour was different in Linux, though, I suppose it may benefit from a more precise counter, but since in Windows it also has a precise counter with time.perf_counter_ns(), I was expecting to see that value change, but it was mainly a confusion with the older time.clock(). On Windows, time.clock() was implemented with QueryPerformanceCounter(). This function became time.perf_counter() in Python 3.4. time.clock() was removed. Use time.get_clock_info('perf_counter') ;-) The PEP 418 introduces new well defined clocks, since time.clock() was not portable. perf_counter and process_time have very different properties. process_time is stopped when the process sleeps, for example. https://docs.python.org/dev/library/time.html#time.perf_counter https://docs.python.org/dev/library/time.html#time.process_time ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:02:15 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 22:02:15 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565820135.82.0.956006356768.issue21131@roundup.psfhosted.org> miss-islington added the comment: New changeset b8e682427a80798fec90dce31392beaf616c3e37 by Miss Islington (bot) in branch '3.8': bpo-21131: Fix faulthandler.register(chain=True) stack (GH-15276) https://github.com/python/cpython/commit/b8e682427a80798fec90dce31392beaf616c3e37 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:03:14 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 22:03:14 +0000 Subject: [issue37775] update doc of compileall In-Reply-To: <1565113080.48.0.890450145581.issue37775@roundup.psfhosted.org> Message-ID: <1565820194.57.0.50068050546.issue37775@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 68e495df909a33e719e3f1ef5b4893ec785e10a4 by Victor Stinner (Hai Shi) in branch 'master': bpo-37775: Update compileall doc for invalidation_mode parameter (GH-15148) https://github.com/python/cpython/commit/68e495df909a33e719e3f1ef5b4893ec785e10a4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:03:22 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 22:03:22 +0000 Subject: [issue37775] update doc of compileall In-Reply-To: <1565113080.48.0.890450145581.issue37775@roundup.psfhosted.org> Message-ID: <1565820202.75.0.379432431026.issue37775@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15017 pull_request: https://github.com/python/cpython/pull/15294 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:04:55 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Wed, 14 Aug 2019 22:04:55 +0000 Subject: [issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc In-Reply-To: <1563731175.2.0.136240000148.issue37645@roundup.psfhosted.org> Message-ID: <1565820295.1.0.194042479596.issue37645@roundup.psfhosted.org> Change by Jeroen Demeyer : ---------- pull_requests: +15018 pull_request: https://github.com/python/cpython/pull/15295 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:09:42 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 22:09:42 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565820582.27.0.39690663706.issue21131@roundup.psfhosted.org> miss-islington added the comment: New changeset 1581d9c405f140491791a07dca3f6166bc499ec1 by Miss Islington (bot) in branch '3.7': bpo-21131: Fix faulthandler.register(chain=True) stack (GH-15276) https://github.com/python/cpython/commit/1581d9c405f140491791a07dca3f6166bc499ec1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:13:53 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 22:13:53 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565820833.38.0.916054924331.issue21131@roundup.psfhosted.org> STINNER Victor added the comment: "I can confirm that on the specific hardware I could reproduce this, that PR14276 and setting the stacksize to SIGSTKSZ*2 passes the test_faulthandler test." Thanks for testing. I merged my PR. About PR 13649, I'm not sure that _PyThread_preferred_stacksize() is still relevant, since my change fixed test_faulthandler test_register_chain(). I chose my change since it's less invasive: it only impacts faulthandler, and it minimalizes the memory usage (especially when faulthandler is not used). Python/thread_pthread.h refactor changes of PR 13649 are interested. Would you like to extract them into a new PR which doesn't add _PyThread_preferred_stacksize() but just add new PLATFORM_xxx macros? -- Maybe test_faulthandler will fail tomorrow on a new platform, but I prefer to open a discussion once such case happens, rather than guessing how faulthandler can crash on an hypothetical platforms. I'm sure that libc developers are well aware of the FPU state size and update SIGSTKSZ accordingly. glibc code computing xsave_state_size: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/cpu-features.c;h=4bab1549132fe8a4c203a70b8c7a51c1dc304049;hb=HEAD#l223 -- If tomorrow, it becomes too hard to choose a good default value for faulthandler stack size, another workaround would be to make it configurable, as Python lets developers choose the thread stack size: _thread.stack_size(size). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:15:57 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 22:15:57 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1565820957.94.0.784963545908.issue21131@roundup.psfhosted.org> STINNER Victor added the comment: The bug has been fixed in 3.7, 3.8 and master (future 3.9) branches. I close the issue. Thanks to everyone who was involved to report the bug and help to find the root issue! The relationship between faulthandler, the Linux kernel version, CPU model, and the FPU state size wasn't obvious at the first look ;-) If someone wants to cleanup/rework how Python handles thread stack size, please open a separated issue. I prefer to restrict this issue to test_faulthandler.test_register_chain() (which is now fixed). ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8, Python 3.9 -Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:22:05 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 14 Aug 2019 22:22:05 +0000 Subject: [issue37775] update doc of compileall In-Reply-To: <1565113080.48.0.890450145581.issue37775@roundup.psfhosted.org> Message-ID: <1565821325.94.0.592294844694.issue37775@roundup.psfhosted.org> miss-islington added the comment: New changeset dbe4c286ce28402c3bce71d568ae55b91280e777 by Miss Islington (bot) in branch '3.8': bpo-37775: Update compileall doc for invalidation_mode parameter (GH-15148) https://github.com/python/cpython/commit/dbe4c286ce28402c3bce71d568ae55b91280e777 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:23:41 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 14 Aug 2019 22:23:41 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565821421.25.0.273013351915.issue37834@roundup.psfhosted.org> Steve Dower added the comment: > Perhaps the best we can do is an additional test where we GetFinalPathName, strip the prefix, reopen the file, GetFinalPathName again and if they match then return it without the prefix. That should handle the both long path settings as transparently as we can. I tried this and the downside (other than hitting the filesystem a few more times) is that any unresolvable path is going to come back with the prefix - e.g. symlink cycles and dangling links. Maybe that's okay? The paths are going to be as valid as they can get (that is, unusable :) ) and it at least means that long paths and deliberately unnormalized paths. Posted an update to PR 15287 with that change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:31:07 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 14 Aug 2019 22:31:07 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1565821867.16.0.991630360882.issue9949@roundup.psfhosted.org> Steve Dower added the comment: FYI, there's been some discussion of this on issue37834, as the issues quickly became conflated. There's also issue14094 which is a dup of this one, but with a different patch. --- To move the relevant discussion here, my current PR is basically the tests from the last attached patch here plus a simpler implementation for non-strict resolution. Right now the big open question is how to deal with the \\?\ prefix. My last two commits will leave it alone if it was in the initial path, and otherwise strip it if the non-prefixed path resolves to the same path as the prefixed path (the _getfinalpathname always returns a prefixed path). The downside of this is that any unresolvable symlinks (dangling links, cycles, etc.) will now be returned with the prefix, whereas previously they were being returned without any attempt to resolve them being made (not because they are invalid, but because the old code wasn't attempting to resolve anything at all). I kinda feel like this is okay, but would appreciate any other opinions on the matter. The alternative is to always strip the prefix, which could make some valid paths become invalid (for example, the one in the new test_realpath_symlink_prefix). ---------- nosy: +eryksun versions: +Python 3.8, Python 3.9 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:36:46 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 22:36:46 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1565822206.3.0.28278850832.issue9949@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:38:37 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 22:38:37 +0000 Subject: [issue37811] [FreeBSD, OSX] Socket module: incorrect usage of poll(2) In-Reply-To: <1565468971.21.0.481323607597.issue37811@roundup.psfhosted.org> Message-ID: <1565822317.34.0.15114711095.issue37811@roundup.psfhosted.org> STINNER Victor added the comment: Thanks Artem Khramov for the nice analysis of the root issue! And thanks for the fix! The bug is now fixed in 3.7, 3.8 and master branches. Python 2.7 is not affected: I added sock_call_ex() helper function in Python 3 when I implemeneted the PEP 475 (Retry system calls failing with EINTR). ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:46:51 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 22:46:51 +0000 Subject: [issue36732] test_asyncio: test_huge_content_recvinto() fails randomly In-Reply-To: <1556264661.54.0.31283754406.issue36732@roundup.psfhosted.org> Message-ID: <1565822811.32.0.0687641250824.issue36732@roundup.psfhosted.org> STINNER Victor added the comment: Recent failure on AMD64 Windows7 SP1 3.8: https://buildbot.python.org/all/#/builders/208/builds/268 test_huge_content_recvinto (test.test_asyncio.test_sock_lowlevel.ProactorEventLoopTests) ... C:\buildbot.python.org\3.8.kloth-win64\build\lib\test\support\__init__.py:1637: ResourceWarning: unclosed ResourceWarning: Enable tracemalloc to get the object allocation traceback ERROR: test_huge_content (test.test_asyncio.test_sock_lowlevel.ProactorEventLoopTests) Re-running failed tests in verbose mode C:\buildbot.python.org\3.8.kloth-win64\build\lib\test\support\__init__.py:1637: ResourceWarning: unclosed ResourceWarning: Enable tracemalloc to get the object allocation traceback FAIL: test_huge_content_recvinto (test.test_asyncio.test_sock_lowlevel.SelectEventLoopTests) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:53:52 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 14 Aug 2019 22:53:52 +0000 Subject: [issue36732] test_asyncio: test_huge_content_recvinto() fails randomly In-Reply-To: <1556264661.54.0.31283754406.issue36732@roundup.psfhosted.org> Message-ID: <1565823232.61.0.663609710785.issue36732@roundup.psfhosted.org> Andrew Svetlov added the comment: ResourceWarning? I'll take a look ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:54:01 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 14 Aug 2019 22:54:01 +0000 Subject: [issue36732] test_asyncio: test_huge_content_recvinto() fails randomly In-Reply-To: <1556264661.54.0.31283754406.issue36732@roundup.psfhosted.org> Message-ID: <1565823241.92.0.357410805225.issue36732@roundup.psfhosted.org> Change by Andrew Svetlov : ---------- assignee: -> asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 18:59:50 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 14 Aug 2019 22:59:50 +0000 Subject: [issue36732] test_asyncio: test_huge_content_recvinto() fails randomly In-Reply-To: <1556264661.54.0.31283754406.issue36732@roundup.psfhosted.org> Message-ID: <1565823590.26.0.0170500402583.issue36732@roundup.psfhosted.org> STINNER Victor added the comment: > ResourceWarning? That's a small bug in the test, but the main issue is that test_huge_content_recvinto() has a race condition. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 19:18:03 2019 From: report at bugs.python.org (Clive Bruton) Date: Wed, 14 Aug 2019 23:18:03 +0000 Subject: [issue37861] Install fails on MacOS X 10.6 with python >= 3.7.1 Message-ID: <1565824683.85.0.593386949201.issue37861@roundup.psfhosted.org> New submission from Clive Bruton : When attempting to install Python >= 3.7.1 on MacOS X 10.6 the installer fails with the message: **** The operation couldn?t be completed. (com.apple.installer.pagecontroller error -1.) Couldn't open "python-3.7.x-macosx10.6.pkg". **** The installer runs without incident with the 3.7.0 installer. Console reports (when "python-3.7.4-macosx10.6.pkg" is run): *** 15/08/2019 00:03:57 Installer[516] @(#)PROGRAM:Install PROJECT:Install-596.1 15/08/2019 00:03:57 Installer[516] @(#)PROGRAM:Installer PROJECT:Installer-430.1 15/08/2019 00:03:57 Installer[516] Hardware: Macmini2,1 @ 1.83 GHz (x 2), 2048 MB RAM 15/08/2019 00:03:57 Installer[516] Running OS Build: Mac OS X 10.6.8 (10K549) 15/08/2019 00:03:57 kernel Installer (map: 0x5a9770c) triggered DYLD shared region unnest for map: 0x5a9770c, region 0x7fff83400000->0x7fff83600000. While not abnormal for debuggers, this increases system memory footprint until the target exits. 15/08/2019 00:03:58 Installer[516] Failed to verify data against certificate. 15/08/2019 00:03:58 Installer[516] Invalid Distribution File/Package **** Similar reports are available here: https://python-forum.io/Thread-Cannot-Install-python-3-7-3-macosx10-6-pkg ---------- components: Installation files: grab1.png messages: 349776 nosy: typonaut priority: normal severity: normal status: open title: Install fails on MacOS X 10.6 with python >= 3.7.1 type: crash versions: Python 3.7 Added file: https://bugs.python.org/file48543/grab1.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 19:19:40 2019 From: report at bugs.python.org (Clive Bruton) Date: Wed, 14 Aug 2019 23:19:40 +0000 Subject: [issue37861] Install fails on MacOS X 10.6 with python >= 3.7.1 In-Reply-To: <1565824683.85.0.593386949201.issue37861@roundup.psfhosted.org> Message-ID: <1565824780.15.0.75127482676.issue37861@roundup.psfhosted.org> Clive Bruton added the comment: Additional screen grab shows hardware/OS version. ---------- Added file: https://bugs.python.org/file48544/grab2.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 19:22:43 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 14 Aug 2019 23:22:43 +0000 Subject: [issue37855] Compiling Python 3.7.4 with Intel compilers 2019 In-Reply-To: <1565808494.42.0.743401642234.issue37855@roundup.psfhosted.org> Message-ID: <1565824963.14.0.263041087158.issue37855@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Seems related : https://bugs.python.org/issue35473 ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 19:31:35 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 14 Aug 2019 23:31:35 +0000 Subject: [issue37861] Install fails on MacOS X 10.6 with python >= 3.7.1 In-Reply-To: <1565824683.85.0.593386949201.issue37861@roundup.psfhosted.org> Message-ID: <1565825495.07.0.555840743446.issue37861@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- components: +macOS nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 19:40:25 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 14 Aug 2019 23:40:25 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565826025.15.0.21938145316.issue37834@roundup.psfhosted.org> Steve Dower added the comment: And I just posted an update to PR 15231 with essentially a rewrite of stat() on Windows. Should be better than it was :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 19:49:31 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Wed, 14 Aug 2019 23:49:31 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565826571.05.0.24296177243.issue29535@roundup.psfhosted.org> Ashwin Ramaswami added the comment: Randomizing the hash of datetime objects was first proposed in https://bugs.python.org/issue13703#msg151796. For the same reasons as str and bytes are non-deterministically hashed in in PEP 456, shouldn't numerics, datetime objects, and tuples be non-deterministically hashed as well? This is for the reason that they can all be used as dictionary keys (additionally, hash(n) begins to repeat when n is a large enough number) -- so it seems like they are also susceptible to the hash collision DoS attacks. ---------- nosy: +dmalcolm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 21:13:06 2019 From: report at bugs.python.org (Kim Oldfield) Date: Thu, 15 Aug 2019 01:13:06 +0000 Subject: [issue37862] Search doesn't find built-in functions Message-ID: <1565831586.7.0.196033639625.issue37862@roundup.psfhosted.org> New submission from Kim Oldfield : The python 3 documentation search https://docs.python.org/3/search.html doesn't always find built-in functions. For example, searching for "zip" takes me to https://docs.python.org/3/search.html?q=zip I would expect the first match to be a link to https://docs.python.org/3/library/functions.html#zip but I can't see a link to this page anywhere in the 146 results. ---------- assignee: docs at python components: Documentation messages: 349781 nosy: docs at python, kim.oldfield priority: normal severity: normal status: open title: Search doesn't find built-in functions type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 21:15:14 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 15 Aug 2019 01:15:14 +0000 Subject: [issue37848] More fully implement Unicode's case mappings In-Reply-To: <1565761340.97.0.731805225537.issue37848@roundup.psfhosted.org> Message-ID: <1565831714.22.0.63458264585.issue37848@roundup.psfhosted.org> Benjamin Peterson added the comment: Greg has read my mind. An optional parameter to upper/lower/casefold was exactly the API I was thinking of. No C locales or the locale module involved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 21:18:59 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 15 Aug 2019 01:18:59 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1565831939.89.0.872903332864.issue37760@roundup.psfhosted.org> Benjamin Peterson added the comment: New changeset 3e4498d35c34aeaf4a9c3d57509b0d3277048ac6 by Benjamin Peterson (Greg Price) in branch 'master': bpo-37760: Avoid cluttering work tree with downloaded Unicode files. (GH-15128) https://github.com/python/cpython/commit/3e4498d35c34aeaf4a9c3d57509b0d3277048ac6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 21:22:38 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 15 Aug 2019 01:22:38 +0000 Subject: [issue32771] merge the underlying data stores of unicodedata and the str type In-Reply-To: <1517797199.65.0.467229070634.issue32771@psf.upfronthosting.co.za> Message-ID: <1565832158.86.0.906804669824.issue32771@roundup.psfhosted.org> Benjamin Peterson added the comment: It's also possible we're missing some logical compression opportunities by artificially partitioning the Unicode databases. Encoded optimally, the combined databases could very well take up less space than their raw sum suggests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 21:24:14 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 15 Aug 2019 01:24:14 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1565778336.83.0.280142443658.issue37760@roundup.psfhosted.org> Message-ID: <83df210e-df05-4894-b3c4-c53d67bb6639@www.fastmail.com> Benjamin Peterson added the comment: On Wed, Aug 14, 2019, at 03:25, STINNER Victor wrote: > > STINNER Victor added the comment: > > > From my perspective, the main problem with using type annotations is that there's nothing checking them in CI. > > Even if unchecked, type annotations can serve as builtin documentation, > as docstrings (even when docstrings are not checked ;-)). Yes, but no one has the expectation that docstrings are automatically verified in any way. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 21:49:10 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 15 Aug 2019 01:49:10 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565833750.46.0.540959287808.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > I wish we could remove the MAX_PATH limit in this case. > > The problem is that we have to remove the limit in any case where the > resulting path might be used, which is what we're already trying to > encourage by supporting long paths. Maybe it's better to ignore the MAX_PATH limit and let processes fail hard if they lack long-path support. A known and expected exception is better than unpredictable behavior (see the next paragraph for an example). That leaves the problem of a final component that's a reserved name, i.e. a DOS device name or a name with trailing dots or spaces. We have no choice but to return this case as an extended path. The intersection of this problem with SetCurrentDirectoryW (os.chdir) troubles me. Without long-path support, the current-directory buffer in the process parameters is hard limited to MAX_PATH, and passing SetCurrentDirectoryW an extended path can't work around this. Fair enough. But it still accepts a device path as the current directory, even though the docs do not explicitly allow it, and the implementation assumes it's disallowed. The combination is an ugly bug: >>> os.chdir('//./C:/Temp') >>> os.getcwd() '\\\\.\\C:\\Temp' >>> os.path._getfullpathname('/spam/eggs') '\\\\spam\\eggs' >>> os.chdir('//?/C:/Temp') >>> os.getcwd() '\\\\?\\C:\\Temp' >>> os.path._getfullpathname('/spam/eggs') '\\\\spam\\eggs' In order to resolve a rooted path such as "/spam/eggs", the runtime library needs to be able to figure out the current drive from the current directory. It checks for a UNC path and otherwise assumes it's a DOS drive, since it's assuming device paths aren't allowed. It ends up assuming the current directory is a DOS drive and grabs the first two characters as the drive name, which is "\\\\". Then when joining the rooted path to this 'drive', the initial slash or backslash of the rooted path gets collapsed into the preceding backslash. The result is at best a broken path, and at worst an unrelated UNC path that exists. I think os.chdir should raise an exception when passed a device path. In explanation, we can point to the documentation of SetCurrentDirectoryW, which explicitly states the following: Each process has a single current directory made up of two parts: * A disk designator that is either a drive letter followed by a colon, or a server name and share name (\\servername\sharename) * A directory on the disk designator > Perhaps the best we can do is an additional test where we > GetFinalPathName, strip the prefix, reopen the file, > GetFinalPathName again and if they match then return it > without the prefix. That should handle the both long path > settings as transparently as we can. I assume you're talking about realpath() here, toward the end where we're working with a solid path, or rather where we have at least the beginning part of the path as a solid path, up to the first component that's inaccessible. For the problem of reserved names, GetFullPathNameW is all we need. This doesn't address the MAX_PATH issue. But that either works or not. It's a user-mode issue. There's nothing to resolve in the kernel. If the path is too long, then CreateFileW will fail at RtlDosPathNameToRelativeNtPathName_U_WithStatus with STATUS_NAME_TOO_LONG, before making a single system call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 21:59:20 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 15 Aug 2019 01:59:20 +0000 Subject: [issue36890] python-3.7.3-macosx10.6.pkg verification error on macOS 10.6 Snow Leopard In-Reply-To: <1557598786.16.0.639636022435.issue36890@roundup.psfhosted.org> Message-ID: <1565834360.0.0.962781811772.issue36890@roundup.psfhosted.org> Ned Deily added the comment: Sorry, I did not get around to trying to repackage 3.7.3 and, since then, 3.7.4 has been released and someone else has now run into this problem on 10.6. As my Python time is very limited at the moment, rather than trying to find a build solution to make signed flat packages (.pkg) files work on 10.6 again, I have uploaded a copy of the old-style bundle installer disk image file (.dmg) for 3.7.4 which is still produced as an artifact of the build process for our installers so the Python files it installs are identical to those installed by the 10.6 pkg install. Bundle-format installer packages no longer work on modern versions of macOS but should still be OK for 10.6. Please test and let me know if it works for you for 10.6 and I'll add it to the 3.7.4 release page. However, as Ronald noted, be aware that we plan to no longer provide the 10.6 variant installers for Python 3.8.x. The dmg installer and its PGP signature file are downloadable here: https://www.python.org/ftp/python/3.7.4/python-3.7.4-macosx10.6.dmg https://www.python.org/ftp/python/3.7.4/python-3.7.4-macosx10.6.dmg.asc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 22:03:16 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 15 Aug 2019 02:03:16 +0000 Subject: [issue37861] Install fails on MacOS X 10.6 with python >= 3.7.1 In-Reply-To: <1565824683.85.0.593386949201.issue37861@roundup.psfhosted.org> Message-ID: <1565834596.03.0.73668145032.issue37861@roundup.psfhosted.org> Ned Deily added the comment: Thanks for the report. This problem was reported earlier for 3.7.3 in Issue36890. As described there, I have now uploaded a copy of the old bundle-format installer dmg file for 3.7.4 that should work on 10.6. See msg349787 there for details and comment there if that solution works for you. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> python-3.7.3-macosx10.6.pkg verification error on macOS 10.6 Snow Leopard type: crash -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 22:30:45 2019 From: report at bugs.python.org (Tim Peters) Date: Thu, 15 Aug 2019 02:30:45 +0000 Subject: [issue37863] Speed hash(fractions.Fraction) Message-ID: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> New submission from Tim Peters : Recording before I forget. These are easy: 1. As the comments note, cache the hash code. 2. Use the new (in 3.8) pow(denominator, -1, modulus) to get the inverse instead of raising to the modulus-2 power. Should be significantly faster. If not, the new "-1" implementation should be changed ;-) Will require catching ValueError in case the denom is a multiple of the modulus. 3. Instead of multiplying by the absolute value of the numerator, multiply by the hash of the absolute value of the numerator. That changes the multiplication, and the subsequent modulus operation, from unbounded-length operations to short bounded-length ones. Hashing the numerator on its own should be significantly faster, because the int hash doesn't require any multiplies or divides regardless of how large the numerator is. None of those should change any computed results. ---------- messages: 349789 nosy: tim.peters priority: low severity: normal stage: needs patch status: open title: Speed hash(fractions.Fraction) type: performance versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 22:40:27 2019 From: report at bugs.python.org (ppperry) Date: Thu, 15 Aug 2019 02:40:27 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1565836827.08.0.156638624925.issue37863@roundup.psfhosted.org> Change by ppperry : ---------- title: Speed hash(fractions.Fraction) -> Speed up hash(fractions.Fraction) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 23:17:09 2019 From: report at bugs.python.org (Greg Price) Date: Thu, 15 Aug 2019 03:17:09 +0000 Subject: [issue36502] str.isspace() for U+00A0 and U+202F differs from document In-Reply-To: <1554186967.56.0.21483381742.issue36502@roundup.psfhosted.org> Message-ID: <1565839029.16.0.998373945497.issue36502@roundup.psfhosted.org> Change by Greg Price : ---------- pull_requests: +15019 pull_request: https://github.com/python/cpython/pull/15296 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 23:25:12 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 03:25:12 +0000 Subject: [issue23505] Urlparse insufficient validation leads to open redirect In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za> Message-ID: <1565839512.52.0.944647872528.issue23505@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- nosy: +epicfaace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 23:25:46 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 03:25:46 +0000 Subject: [issue1722348] urlparse.urlunparse forms file urls incorrectly Message-ID: <1565839546.57.0.364734494387.issue1722348@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- nosy: +epicfaace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 23:26:20 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 03:26:20 +0000 Subject: [issue32084] [Security] http.server can be abused to redirect to (almost) arbitrary URL In-Reply-To: <1511185756.0.0.213398074469.issue32084@psf.upfronthosting.co.za> Message-ID: <1565839580.69.0.0834708908051.issue32084@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- nosy: +epicfaace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 23:28:56 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 03:28:56 +0000 Subject: [issue34276] urllib.parse doesn't round-trip file URI's with multiple leading slashes In-Reply-To: <1532925543.25.0.56676864532.issue34276@psf.upfronthosting.co.za> Message-ID: <1565839736.85.0.98552498448.issue34276@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- nosy: +epicfaace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 23:29:05 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 03:29:05 +0000 Subject: [issue34276] urllib.parse doesn't round-trip file URI's with multiple leading slashes In-Reply-To: <1532925543.25.0.56676864532.issue34276@psf.upfronthosting.co.za> Message-ID: <1565839745.48.0.483074495171.issue34276@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- keywords: +patch pull_requests: +15020 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15297 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 23:49:46 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 15 Aug 2019 03:49:46 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1565840986.03.0.256662648834.issue37863@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +15021 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15298 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 14 23:51:58 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 15 Aug 2019 03:51:58 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1565841118.73.0.843080905585.issue37863@roundup.psfhosted.org> Raymond Hettinger added the comment: I make a quick PR for you. Skipped #1 because I don't think Fraction hashing is worth adding another slot. ---------- nosy: +mark.dickinson, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:03:23 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 04:03:23 +0000 Subject: [issue28778] wsgiref HTTP Response Header Injection: CRLF Injection In-Reply-To: <1479891172.05.0.173710900147.issue28778@psf.upfronthosting.co.za> Message-ID: <1565841803.85.0.867888801512.issue28778@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- nosy: +epicfaace versions: +Python 3.9 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:03:30 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 04:03:30 +0000 Subject: [issue11671] Security hole in wsgiref.headers.Headers In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za> Message-ID: <1565841810.2.0.42311209858.issue11671@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- nosy: +epicfaace versions: +Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:09:21 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 04:09:21 +0000 Subject: [issue22928] HTTP header injection in urrlib2/urllib/httplib/http.client (CVE-2016-5699) In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za> Message-ID: <1565842161.33.0.926884318521.issue22928@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- pull_requests: +15023 pull_request: https://github.com/python/cpython/pull/15299 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:09:21 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 04:09:21 +0000 Subject: [issue11671] Security hole in wsgiref.headers.Headers In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za> Message-ID: <1565842161.22.0.903625393025.issue11671@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- pull_requests: +15022 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15299 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:09:43 2019 From: report at bugs.python.org (Greg Price) Date: Thu, 15 Aug 2019 04:09:43 +0000 Subject: [issue32771] merge the underlying data stores of unicodedata and the str type In-Reply-To: <1517797199.65.0.467229070634.issue32771@psf.upfronthosting.co.za> Message-ID: <1565842183.59.0.500809540632.issue32771@roundup.psfhosted.org> Greg Price added the comment: > About the RSS memory, I'm not sure how Linux accounts the Unicode databases before they are accessed. Is it like read-only memory loaded on demand when accessed? It stands for "resident set size", as in "resident in memory"; and it only counts pages of real physical memory. The intention is to count up pages that the process is somehow using. Where the definition potentially gets fuzzy is if this process and another are sharing some memory. I don't know much about how that kind of edge case is handled. But one thing I think it's pretty consistently good at is not counting pages that you've nominally mapped from a file, but haven't actually forced to be loaded physically into memory by actually looking at them. That is: say you ask for a file (or some range of it) to be mapped into memory for you. This means it's now there in the address space, and if the process does a load instruction from any of those addresses, the kernel will ensure the load instruction works seamlessly. But: most of it won't be eagerly read from disk or loaded physically into RAM. Rather, the kernel's counting on that load instruction causing a page fault; and its page-fault handler will take care of reading from the disk and sticking the data physically into RAM. So until you actually execute some loads from those addresses, the data in that mapping doesn't contribute to the genuine demand for scarce physical RAM on the machine; and it also isn't counted in the RSS number. Here's a demo! This 262392 kiB (269 MB) Git packfile is the biggest file lying around in my CPython directory: $ du -k .git/objects/pack/pack-0e4acf3b2d8c21849bb11d875bc14b4d62dc7ab1.pack 262392 .git/objects/pack/pack-0e4acf3b2d8c21849bb11d875bc14b4d62dc7ab1.pack Open it for read -- adds 100 kiB, not sure why: $ python Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os, mmap >>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") VmRSS: 9968 kB >>> fd = os.open('.git/objects/pack/pack-0e4acf3b2d8c21849bb11d875bc14b4d62dc7ab1.pack', os.O_RDONLY) >>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") VmRSS: 10068 kB Map it into our address space -- RSS doesn't budge: >>> m = mmap.mmap(fd, 0, prot=mmap.PROT_READ) >>> m >>> len(m) 268684419 >>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") VmRSS: 10068 kB Cause the process to actually look at all the data (this takes about ~10s, too)... >>> sum(len(l) for l in m) 268684419 >>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") VmRSS: 271576 kB RSS goes way up, by 261508 kiB! Oddly slightly less (by ~1MB) than the file's size. But wait, there's more. Drop that mapping, and RSS goes right back down (OK, keeps 8 kiB extra): >>> del m >>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") VmRSS: 10076 kB ... and then map the exact same file again, and it's *still* down: >>> m = mmap.mmap(fd, 0, prot=mmap.PROT_READ) >>> os.system(f"grep ^VmRSS /proc/{os.getpid()}/status") VmRSS: 10076 kB This last step is interesting because it's a certainty that the data is still physically in memory -- this is my desktop, with plenty of free RAM. And it's even in our address space. But because we haven't actually loaded from those addresses, it's still in memory only at the kernel's caching whim, and so apparently our process doesn't get "charged" or "blamed" for its presence there. In the case of running an executable with a bunch of data in it, I expect that the bulk of the data (and of the code for that matter) winds up treated very much like the file contents we mmap'd in. It's mapped but not eagerly physically loaded; so it doesn't contribute to the RSS number, nor to the genuine demand for scarce physical RAM on the machine. That's a bit long :-), but hopefully informative. In short, I think for us RSS should work well as a pretty faithful measure of the real memory consumption that we want to be frugal with. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:12:13 2019 From: report at bugs.python.org (Greg Price) Date: Thu, 15 Aug 2019 04:12:13 +0000 Subject: [issue37758] unicodedata checksum-tests only test 1/17th of Unicode's codepoints In-Reply-To: <1564967162.48.0.525882022653.issue37758@roundup.psfhosted.org> Message-ID: <1565842333.14.0.627554637734.issue37758@roundup.psfhosted.org> Change by Greg Price : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:21:43 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 04:21:43 +0000 Subject: [issue28778] wsgiref HTTP Response Header Injection: CRLF Injection In-Reply-To: <1479891172.05.0.173710900147.issue28778@psf.upfronthosting.co.za> Message-ID: <1565842903.59.0.147657333785.issue28778@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:21:51 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 04:21:51 +0000 Subject: [issue28778] wsgiref HTTP Response Header Injection: CRLF Injection In-Reply-To: <1479891172.05.0.173710900147.issue28778@psf.upfronthosting.co.za> Message-ID: <1565842911.19.0.397796704954.issue28778@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- keywords: +patch pull_requests: +15024 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15299 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:22:13 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 04:22:13 +0000 Subject: [issue11671] Security hole in wsgiref.headers.Headers In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za> Message-ID: <1565842933.42.0.238832506587.issue11671@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:24:05 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 04:24:05 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565843045.37.0.268973445851.issue37764@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:40:26 2019 From: report at bugs.python.org (Greg Price) Date: Thu, 15 Aug 2019 04:40:26 +0000 Subject: [issue37864] Correct and deduplicate docs on "printable" characters Message-ID: <1565844026.38.0.454772996752.issue37864@roundup.psfhosted.org> New submission from Greg Price : While working on #36502 and then #18236 about the definition and docs of str.isspace(), I looked closely also at its neighbor str.isprintable(). It turned out that we have the definition of what makes a character "printable" documented in three places, giving two different definitions. The definition in the comment on `_PyUnicode_IsPrintable` is inverted, so that's an easy small fix. With that correction, the two definitions turn out to be equivalent -- but to confirm that, you have to go look up, or happen to know, that those are the only five "Other" categories and only three "Separator" categories in the Unicode character database. That makes it hard for the reader to tell whether they really are the same, or if there's some subtle difference in the intended semantics. I've taken a crack at writing some improved docs text for a single definition, borrowing ideas from the C comment as well as the existing docs text; and then pointing there from the other places we'd had definitions. PR coming shortly. ---------- components: Unicode messages: 349792 nosy: Greg Price, ezio.melotti, vstinner priority: normal severity: normal status: open title: Correct and deduplicate docs on "printable" characters versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:43:18 2019 From: report at bugs.python.org (Greg Price) Date: Thu, 15 Aug 2019 04:43:18 +0000 Subject: [issue37864] Correct and deduplicate docs on "printable" characters In-Reply-To: <1565844026.38.0.454772996752.issue37864@roundup.psfhosted.org> Message-ID: <1565844198.61.0.184366145374.issue37864@roundup.psfhosted.org> Change by Greg Price : ---------- keywords: +patch pull_requests: +15025 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15300 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:48:01 2019 From: report at bugs.python.org (Greg Price) Date: Thu, 15 Aug 2019 04:48:01 +0000 Subject: [issue36502] str.isspace() for U+00A0 and U+202F differs from document In-Reply-To: <1554186967.56.0.21483381742.issue36502@roundup.psfhosted.org> Message-ID: <1565844481.98.0.780038838124.issue36502@roundup.psfhosted.org> Change by Greg Price : ---------- pull_requests: +15026 pull_request: https://github.com/python/cpython/pull/15301 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 00:52:54 2019 From: report at bugs.python.org (Greg Price) Date: Thu, 15 Aug 2019 04:52:54 +0000 Subject: [issue37758] unicodedata checksum-tests only test 1/17th of Unicode's codepoints In-Reply-To: <1564967162.48.0.525882022653.issue37758@roundup.psfhosted.org> Message-ID: <1565844774.31.0.224606591249.issue37758@roundup.psfhosted.org> Change by Greg Price : ---------- pull_requests: +15027 pull_request: https://github.com/python/cpython/pull/15302 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 02:05:10 2019 From: report at bugs.python.org (Zackery Spytz) Date: Thu, 15 Aug 2019 06:05:10 +0000 Subject: [issue37852] Pickling doesn't work for name-mangled private methods In-Reply-To: <1565801916.64.0.686845199304.issue37852@roundup.psfhosted.org> Message-ID: <1565849110.14.0.584286952164.issue37852@roundup.psfhosted.org> Zackery Spytz added the comment: This seems like a duplicate of bpo-33007. ---------- nosy: +ZackerySpytz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 02:48:05 2019 From: report at bugs.python.org (Antal Nemes) Date: Thu, 15 Aug 2019 06:48:05 +0000 Subject: [issue36753] Python modules not linking to libpython causes issues for RTLD_LOCAL system-wide In-Reply-To: <1556554560.81.0.844742203447.issue36753@roundup.psfhosted.org> Message-ID: <1565851685.86.0.528857324135.issue36753@roundup.psfhosted.org> Change by Antal Nemes : ---------- nosy: +furiel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 03:43:15 2019 From: report at bugs.python.org (Andrei Pashkin) Date: Thu, 15 Aug 2019 07:43:15 +0000 Subject: [issue37865] tempfile.NamedTemporaryFile() raises exception on close() when file is absent Message-ID: <1565854995.12.0.82543629972.issue37865@roundup.psfhosted.org> New submission from Andrei Pashkin : Here is an example: import tempfile import os with tempfile.NamedTemporaryFile() as temp: os.remove(temp.name) And here is an error it produces: Traceback (most recent call last): File "test.py", line 6, in os.remove(temp.name) File "/usr/lib/python3.7/tempfile.py", line 639, in __exit__ self.close() File "/usr/lib/python3.7/tempfile.py", line 646, in close self._closer.close() File "/usr/lib/python3.7/tempfile.py", line 583, in close unlink(self.name) FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tmpzn8gtiz1' ---------- messages: 349794 nosy: pashkin priority: normal severity: normal status: open title: tempfile.NamedTemporaryFile() raises exception on close() when file is absent versions: Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 03:52:29 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 15 Aug 2019 07:52:29 +0000 Subject: [issue37865] tempfile.NamedTemporaryFile() raises exception on close() when file is absent In-Reply-To: <1565854995.12.0.82543629972.issue37865@roundup.psfhosted.org> Message-ID: <1565855549.27.0.204660733048.issue37865@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I think this is same as https://bugs.python.org/issue29573 . ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 05:18:25 2019 From: report at bugs.python.org (Hua Liu) Date: Thu, 15 Aug 2019 09:18:25 +0000 Subject: [issue37866] PyModule_GetState Segmentation fault when called Py_Initialize Message-ID: <1565860705.57.0.264365379897.issue37866@roundup.psfhosted.org> Change by Hua Liu : ---------- nosy: Hua Liu priority: normal severity: normal status: open title: PyModule_GetState Segmentation fault when called Py_Initialize type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 05:24:27 2019 From: report at bugs.python.org (Hua Liu) Date: Thu, 15 Aug 2019 09:24:27 +0000 Subject: [issue37866] PyModule_GetState Segmentation fault when called Py_Initialize Message-ID: <1565861067.92.0.349653204842.issue37866@roundup.psfhosted.org> Change by Hua Liu : Added file: https://bugs.python.org/file48545/backtrace.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 05:34:06 2019 From: report at bugs.python.org (Peter Edwards) Date: Thu, 15 Aug 2019 09:34:06 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1565818482.98.0.514854901469.issue21131@roundup.psfhosted.org> Message-ID: Peter Edwards added the comment: On Wed, 14 Aug 2019 at 22:34, STINNER Victor wrote: > > ...I'm not sure that we can fix bpo-37851 in Python 3.7. That's totally reasonable, sure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 05:41:18 2019 From: report at bugs.python.org (Peter Edwards) Date: Thu, 15 Aug 2019 09:41:18 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1565818374.03.0.188467063522.issue21131@roundup.psfhosted.org> Message-ID: Peter Edwards added the comment: On Wed, 14 Aug 2019 at 22:32, STINNER Victor wrote: > > We are talking abou the faulthandler_user() function of > Modules/faulthandler.c. It is implemented in pure C, it doesn't allocate > memory on the heap, it uses a very small set of functions (write(), > sigaction(), raise()) and it tries to minimize its usage of the stack > memory. > I was more concerned about what was happening in the chained handler, which will also run on the restricted stack: I had assumed that was potentially running arbitrary python code. That's actually probably incorrect, now that I think about it, but it's harder to infer much about its stack usage directly in faulthandler.c. I'll take a look (just to satisfy myself, more than anything) > It is very different than the traceback module which is implemented in > pure Python. > Right, totally - I had jumped to the conclusion that it would end up executing in the interpreter via the chain, but, as I say, that's probably wrong. I'm not sure what guarantees the chained signal handler makes about its stack usage. (Will educate myself) > faulthandler is really designed to debug segmentation fault, stack > overflow, Python hang (like a deadlock), etc. > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 05:42:27 2019 From: report at bugs.python.org (Hua Liu) Date: Thu, 15 Aug 2019 09:42:27 +0000 Subject: [issue37866] PyModule_GetState Segmentation fault when called Py_Initialize Message-ID: <1565862147.92.0.832286772909.issue37866@roundup.psfhosted.org> New submission from Hua Liu : the crash file came out when i tried to call Py_Initialize in a C file. Python2.7 and python3.5.3 were installed to my x86-64 box. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 05:52:38 2019 From: report at bugs.python.org (Peter Edwards) Date: Thu, 15 Aug 2019 09:52:38 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1565820833.38.0.916054924331.issue21131@roundup.psfhosted.org> Message-ID: Peter Edwards added the comment: On Wed, 14 Aug 2019 at 23:13, STINNER Victor wrote: > > STINNER Victor added the comment: > > About PR 13649, I'm not sure that _PyThread_preferred_stacksize() is still > relevant, since my change fixed test_faulthandler test_register_chain(). I > chose my change since it's less invasive: it only impacts faulthandler, and > it minimalizes the memory usage (especially when faulthandler is not used). > Sure - there's no reason for it to exist if you don't want to use it to fix the issue here. > Python/thread_pthread.h refactor changes of PR 13649 are interested. Would > you like to extract them into a new PR which doesn't add > _PyThread_preferred_stacksize() but just add new PLATFORM_xxx macros? > Yes, certainly. Maybe test_faulthandler will fail tomorrow on a new platform, but I prefer > to open a discussion once such case happens, rather than guessing how > faulthandler can crash on an hypothetical platforms. Well, one argument for the dynamic approach is that existing python binaries can adjust without needing to be respun for new CPUs. I think SIGSTKSZ is a vestage from when CPU architectures had consistently sized register sets across models. Its interesting to read the comment on the IA64 definition for SIGSTKSZ: https://github.com/torvalds/linux/blob/master/arch/ia64/include/uapi/asm/signal.h#L83 > I'm sure that libc developers are well aware of the FPU state size and > update SIGSTKSZ accordingly. > The current value comes from the kernel sources, and has not changed since at the latest 2005 (with the initial git commit of the kernel), which I think predates xsave/xrestore by some margin. I don't think its a useful measure of anything in the real (x86) world today. > glibc code computing xsave_state_size: > > > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/cpu-features.c;h=4bab1549132fe8a4c203a70b8c7a51c1dc304049;hb=HEAD#l223 > > -- > > If tomorrow, it becomes too hard to choose a good default value for > faulthandler stack size, another workaround would be to make it > configurable, as Python lets developers choose the thread stack size: > _thread.stack_size(size). > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 06:38:42 2019 From: report at bugs.python.org (simon mackenzie) Date: Thu, 15 Aug 2019 10:38:42 +0000 Subject: [issue37867] docs says subprocess.run accepts a string but this does not work on linux Message-ID: <1565865522.62.0.177919974549.issue37867@roundup.psfhosted.org> New submission from simon mackenzie : The docs for subprocess.run say "The arguments used to launch the process. This may be a list or a string." This works in windows but in linux it has to be a list. Either needs fixing or the docs need to be changed. ---------- messages: 349800 nosy: simon mackenzie priority: normal severity: normal status: open title: docs says subprocess.run accepts a string but this does not work on linux _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 06:50:14 2019 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 15 Aug 2019 10:50:14 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565866214.8.0.841796888065.issue29535@roundup.psfhosted.org> Mark Dickinson added the comment: > shouldn't numerics, datetime objects, and tuples be non-deterministically hashed as well? [...] Making the numeric hash non-predictable while maintaining its current properties would be difficult. But fortunately, I don't think it's necessary. IIUC, the original DOS attack involved carefully-crafted collections of keywords and values being passed to a website backend, with that backend then putting those keywords and values into a Python dictionary. I'd expect that there are *way* more places where a dict is being constructed with string keys in this way than with numeric keys. In fact, I think it's reasonable to assume that there are no websites vulnerable to a DOS via *numeric* hash collisions until we see evidence otherwise. FWIW, I'd expect the same to be true for datetime objects; I'm not sure why they were originally included. IANASE, but it seems to me that covering Unicode strings and bytestrings should be enough in practice. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 07:56:34 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 15 Aug 2019 11:56:34 +0000 Subject: [issue37867] docs says subprocess.run accepts a string but this does not work on linux In-Reply-To: <1565865522.62.0.177919974549.issue37867@roundup.psfhosted.org> Message-ID: <1565870194.15.0.897818104529.issue37867@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 08:02:15 2019 From: report at bugs.python.org (Johan Hidding) Date: Thu, 15 Aug 2019 12:02:15 +0000 Subject: [issue37868] `is_dataclass` returns `True` if `getattr` always succeeds. Message-ID: <1565870535.54.0.93577990924.issue37868@roundup.psfhosted.org> New submission from Johan Hidding : Given a class `A` that overloads `__getattr__` ``` class A: def __getattr__(self, key): return 0 ``` An instance of this class is always identified as a dataclass. ``` from dataclasses import is_dataclass a = A() print(is_dataclass(a)) ``` gives the output `True`. Possible fix: check for the instance type. ``` is_dataclass(type(a)) ``` does give the correct answer. ---------- components: Library (Lib) messages: 349802 nosy: Johan Hidding priority: normal severity: normal status: open title: `is_dataclass` returns `True` if `getattr` always succeeds. type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 08:33:32 2019 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 15 Aug 2019 12:33:32 +0000 Subject: [issue37868] `is_dataclass` returns `True` if `getattr` always succeeds. In-Reply-To: <1565870535.54.0.93577990924.issue37868@roundup.psfhosted.org> Message-ID: <1565872412.75.0.119019769946.issue37868@roundup.psfhosted.org> Change by Eric V. Smith : ---------- assignee: -> eric.smith nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 08:47:03 2019 From: report at bugs.python.org (SilentGhost) Date: Thu, 15 Aug 2019 12:47:03 +0000 Subject: [issue37867] docs says subprocess.run accepts a string but this does not work on linux In-Reply-To: <1565865522.62.0.177919974549.issue37867@roundup.psfhosted.org> Message-ID: <1565873223.59.0.22231409286.issue37867@roundup.psfhosted.org> SilentGhost added the comment: The only place this phrase appears is in CompletedProcess.args description and it is correct there. Whether args arguments of subprocess.run (or generally Popen) can be a list or a string is discussed in Frequently Used Arguments section, and it is perfectly clear from reading the text under which condition you can pass a string as args argument. I don't think anything needs fixing, both implementation and docs are correct. ---------- assignee: -> docs at python components: +Documentation nosy: +SilentGhost, docs at python type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 08:52:56 2019 From: report at bugs.python.org (simon mackenzie) Date: Thu, 15 Aug 2019 12:52:56 +0000 Subject: [issue37867] docs says subprocess.run accepts a string but this does not work on linux In-Reply-To: <1565873223.59.0.22231409286.issue37867@roundup.psfhosted.org> Message-ID: simon mackenzie added the comment: Technically true but I am not the first person to have incorrectly interpreted this that it can be a string which suggests it is not clear to the reader. Maybe should be explicitly stated in the description of run as it is not obvious or intuitive. On Thu, 15 Aug 2019 at 13:47, SilentGhost wrote: > > SilentGhost added the comment: > > The only place this phrase appears is in CompletedProcess.args description > and it is correct there. Whether args arguments of subprocess.run (or > generally Popen) can be a list or a string is discussed in Frequently Used > Arguments section, and it is perfectly clear from reading the text under > which condition you can pass a string as args argument. I don't think > anything needs fixing, both implementation and docs are correct. > > ---------- > assignee: -> docs at python > components: +Documentation > nosy: +SilentGhost, docs at python > type: -> behavior > > _______________________________________ > Python tracker > > _______________________________________ > ---------- title: docs says subprocess.run accepts a string but this does not work on linux -> docs says subprocess.run accepts a string but this does not work on linux _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 10:04:59 2019 From: report at bugs.python.org (SilentGhost) Date: Thu, 15 Aug 2019 14:04:59 +0000 Subject: [issue37867] docs says subprocess.run accepts a string but this does not work on linux In-Reply-To: <1565865522.62.0.177919974549.issue37867@roundup.psfhosted.org> Message-ID: <1565877899.94.0.743385738963.issue37867@roundup.psfhosted.org> SilentGhost added the comment: But docs don't say that at all. You're looking at description of an attribute of returned object. And of course it can be a string, under certain conditions. The attributes of CompletedProcess and function arguments are described in the standard way, and I haven't heard of anyone mixing the two before. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 10:17:52 2019 From: report at bugs.python.org (simon mackenzie) Date: Thu, 15 Aug 2019 14:17:52 +0000 Subject: [issue37867] docs says subprocess.run accepts a string but this does not work on linux In-Reply-To: <1565877899.94.0.743385738963.issue37867@roundup.psfhosted.org> Message-ID: simon mackenzie added the comment: Would be clearer if the arguments were listed before the return object. On Thu, 15 Aug 2019 at 15:05, SilentGhost wrote: > > SilentGhost added the comment: > > But docs don't say that at all. You're looking at description of an > attribute of returned object. And of course it can be a string, under > certain conditions. The attributes of CompletedProcess and function > arguments are described in the standard way, and I haven't heard of anyone > mixing the two before. > > ---------- > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 11:02:26 2019 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 15 Aug 2019 15:02:26 +0000 Subject: [issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc In-Reply-To: <1563731175.2.0.136240000148.issue37645@roundup.psfhosted.org> Message-ID: <1565881346.14.0.199294461284.issue37645@roundup.psfhosted.org> Petr Viktorin added the comment: I am not convinced. I'm wary of making error messages depend on the str representation of a function; that would prevent us from changing it later. I'm wary of "%S" used in error messages. Those are for the programmer, not the user, so they should prefer __repr__. I train beginners to recognize "" as a sign of omitted parentheses. The ugliness is useful: it shows you're dealing with an internal object, not a data value. So, I think "" is much better than just "f()". I wouldn't mind "" (maybe even with the full signature), but that doesn't quite help this case. (I don't care much for the "at 0x7f9f4bbe5e18" part, but that's not the issue here.) ---------- nosy: +petr.viktorin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 11:26:40 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 15 Aug 2019 15:26:40 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565882800.4.0.566270599588.issue37834@roundup.psfhosted.org> Steve Dower added the comment: > I assume you're talking about realpath() here ... Yes, and so are you :) Let's move that discussion to issue9949 and/or PR 15287. > I think os.chdir should raise an exception when passed a device path. When the OS starts returning an error code for this case, we can start raising an exception. It might be worth reporting these cases though, as you're right that they don't seem to be handled correctly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 11:49:52 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 15 Aug 2019 15:49:52 +0000 Subject: [issue37207] Use PEP 590 vectorcall to speed up calls to range(), list() and dict() In-Reply-To: <1560072227.25.0.180298594259.issue37207@roundup.psfhosted.org> Message-ID: <1565884192.04.0.853993874186.issue37207@roundup.psfhosted.org> miss-islington added the comment: New changeset 37806f404f57b234902f0c8de9a04647ad01b7f1 by Miss Islington (bot) (Jeroen Demeyer) in branch 'master': bpo-37207: enable vectorcall for type.__call__ (GH-14588) https://github.com/python/cpython/commit/37806f404f57b234902f0c8de9a04647ad01b7f1 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 12:22:22 2019 From: report at bugs.python.org (Brett Cannon) Date: Thu, 15 Aug 2019 16:22:22 +0000 Subject: [issue37860] Add netlify deploy preview for docs In-Reply-To: <1565817286.53.0.142673590989.issue37860@roundup.psfhosted.org> Message-ID: <1565886142.06.0.0814829634799.issue37860@roundup.psfhosted.org> Change by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 12:58:18 2019 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 15 Aug 2019 16:58:18 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1565888298.64.0.472077787449.issue37863@roundup.psfhosted.org> Mark Dickinson added the comment: > Should be significantly faster. If not, the new "-1" implementation should be changed ;-) I wouldn't have bet on this, before seeing Raymond's benchmark results. Writing a fast path for invmod for C-size integers is still on my to-do list; the current implementation does way too many Python-level divisions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 13:37:49 2019 From: report at bugs.python.org (Tim Peters) Date: Thu, 15 Aug 2019 17:37:49 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1565890669.1.0.859298443389.issue37863@roundup.psfhosted.org> Tim Peters added the comment: Why I expected a major speedup from this: the binary exponentiation routine (for "reasonably small" exponents) does 30 * ceiling(exponent.bit_length() / 30) multiply-and-reduces, plus another for each bit set in the exponent. That's a major difference between exponents of bit lengths 61 ((P-2).bit_length()) and 1 ((1).bit_length()). Indeed, I bet it would pay in `long_pow()` to add another test, under the `if (Py_SIZE(b) < 0)` branch, to skip the exponentiation part entirely when b is -1. `long_invmod()` would be the end of it then. Because I expect using an exponent of -1 for modular inverse will be overwhelmingly more common than using any other negative exponent with a modulus. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 13:56:18 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 15 Aug 2019 17:56:18 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565891778.08.0.779477494911.issue37834@roundup.psfhosted.org> Steve Dower added the comment: [Quoting from the PR comments] > traverse is from follow_symlinks and only applies to symlinks. It does not apply to other types of reparse points. I get your argument that junctions are not symlinks, but I disagree that we should try this hard to emulate POSIX semantics rather than letting the OS do its thing. We aren't reparsing anything ourselves (in the PR) - if the OS is configured to do something different because of a reparse point, we're simply going to respect that instead of trying to work around it. A user who has created a directory junction likely wants it to behave as if the directory is actually in that location. Similarly, a user who has created a directory symlink likely wants it to behave as if it were in that location. Powershell treats both the same for high-level operations - the LinkType attribute is the only way to tell them apart (mirrored in the st_reparse_tag field). > If we've opened the reparse point to test for a symlink, we must reopen for all other types The premise here is not true - we've opened the reparse point to get the file attributes. The only reason we look at the reparse tag at all is to raise an error if the user requested traversal and despite that, we ended up at a link, and I'm becoming less convinced that should be an error anyway (this is different from nt.readlink() and ntpath.realpath(), of course, where we want to read the link and return where it points). nt.stat() is trying to read the file attributes, and if they are not accessible then raising is the correct behaviour, so I don't see why we should try any harder than the OS here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 14:01:04 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 15 Aug 2019 18:01:04 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565892064.85.0.56604380126.issue37834@roundup.psfhosted.org> Steve Dower added the comment: Unless your point is that we should _always_ traverse junctions? In which case we have a traverse 'upgrade' scenario (calls to lstat() become calls to stat() when we find out it's a junction). Again, not sure why we'd want to hide the ability to manipulate the junction itself from Python users, except to emulate POSIX. And I'd imagine anyone using lstat() is doing it deliberately to manipulate the link and would prefer we didn't force them to add Windows-specific code that's even more complex. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 14:32:07 2019 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 15 Aug 2019 18:32:07 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1565893927.28.0.803612838967.issue37863@roundup.psfhosted.org> Mark Dickinson added the comment: > That's a major difference between exponents of bit lengths 61 ((P-2).bit_length()) and 1 ((1).bit_length()). Right, but that's stacked up against the cost of the extended Euclidean algorithm for computing the inverse. The extended gcd for computing the inverse of 1425089352415399815 (for example) modulo 2**61 - 1 takes 69 steps, each one of which involves a PyLong quotient-and-remainder division, a PyLong multiplication and a subtraction. So that's at least the same order of magnitude when it comes to number of operations. I'd bet that a dedicated pure C square-and-multiply algorithm (with an addition chain specifically chosen for the target modulus, and with the multiplication and reduction specialised for the particular form of the modulus) would still be the fastest way to go here. I believe optimal addition chains for 2**31-3 are known, and it shouldn't be too hard to find something close-to-optimal (as opposed to proved optimal) for 2**61-3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 14:34:11 2019 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 15 Aug 2019 18:34:11 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1565894051.73.0.431419919488.issue37863@roundup.psfhosted.org> Mark Dickinson added the comment: > Indeed, I bet it would pay in `long_pow()` to add another test, under the `if (Py_SIZE(b) < 0)` branch, to skip the exponentiation part entirely when b is -1. Agreed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 14:48:06 2019 From: report at bugs.python.org (John Levon) Date: Thu, 15 Aug 2019 18:48:06 +0000 Subject: [issue37790] subprocess.Popen() is extremely slow In-Reply-To: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org> Message-ID: <1565894886.61.0.41034365642.issue37790@roundup.psfhosted.org> Change by John Levon : ---------- nosy: +movement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 15:09:10 2019 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 15 Aug 2019 19:09:10 +0000 Subject: [issue37642] timezone allows no offset from range (23:59, 24:00) In-Reply-To: <1563709284.19.0.651842013894.issue37642@roundup.psfhosted.org> Message-ID: <1565896150.21.0.482396433117.issue37642@roundup.psfhosted.org> Paul Ganssle added the comment: New changeset 27b38b99b3a154fa5c25cd67fe01fb4fc04604b0 by Paul Ganssle in branch '3.8': bpo-37642: Update acceptable offsets in timezone (GH-14878) (#15227) https://github.com/python/cpython/commit/27b38b99b3a154fa5c25cd67fe01fb4fc04604b0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 15:09:40 2019 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 15 Aug 2019 19:09:40 +0000 Subject: [issue37642] timezone allows no offset from range (23:59, 24:00) In-Reply-To: <1563709284.19.0.651842013894.issue37642@roundup.psfhosted.org> Message-ID: <1565896180.58.0.169422886547.issue37642@roundup.psfhosted.org> Paul Ganssle added the comment: New changeset ed44b84961eb0e5b97e4866c1455ac4093d27549 by Paul Ganssle in branch '3.7': bpo-37642: Update acceptable offsets in timezone (GH-14878) (#15226) https://github.com/python/cpython/commit/ed44b84961eb0e5b97e4866c1455ac4093d27549 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 15:11:03 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 15 Aug 2019 19:11:03 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565896263.08.0.571582058502.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > Unless your point is that we should _always_ traverse junctions? In > which case we have a traverse 'upgrade' scenario (calls to lstat() > become calls to stat() when we find out it's a junction). If we've opened the reparse point to test IO_REPARSE_TAG_SYMLINK, and that's not the case, then we need to reopen with reparsing enabled. This is exactly what Windows API functions do in order to implement particular behavior for just symlinks or just mountpoints. For example, if we've opened an HSM reparse point, we must reopen to let the file-system filter driver implement its semantics to replace the reparse point with the real file from auxiliary storage and complete the request. That is the stat() result I want when I say stat(filename, follow_symlinks=False) or lstat(filename), because this file is not a symlink. It's implicitly just the file to end users -- despite whatever backend tricks are being played in the kernel to implement other behavior such as HSM. Conflating this with a symlink is not right. Lies catch up with us. We can't copy it as link via os.symlink and os.readlink, and it doesn't get treated like a symlink in API functions. If you want to add an "open reparse point" parameter, that would make sense. It's of some use to get the tag and implement particular behavior for types of reparse points, and particularly for name surrogates, which includes mount points (junctions). As to mount points, yes, I do think we should always traverse them. Please see my extended comment and the follow-up example on GitHub. > Again, not sure why we'd want to hide the ability to manipulate the > junction itself from Python users, except to emulate POSIX. And I'd > imagine anyone using lstat() is doing it deliberately to manipulate > the link and would prefer we didn't force them to add Windows- > specific code that's even more complex. A mount point is not a link. ismount() and islink() can never both be true. Also, a POSIX symlink can never be a directory, which is why we make stat() pretend directory symlinks aren't directories. If the user wants a link, they can use a symlink that's created by os.symlink, mklink, new-item -type SymbolicLink, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 15:11:42 2019 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 15 Aug 2019 19:11:42 +0000 Subject: [issue37642] timezone allows no offset from range (23:59, 24:00) In-Reply-To: <1563709284.19.0.651842013894.issue37642@roundup.psfhosted.org> Message-ID: <1565896302.82.0.93134408916.issue37642@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 Aug 15 15:19:27 2019 From: report at bugs.python.org (Tim Peters) Date: Thu, 15 Aug 2019 19:19:27 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1565896767.81.0.870713229677.issue37863@roundup.psfhosted.org> Tim Peters added the comment: Well, details matter ;-) Division in Python is expensive. In the exponentiation algorithm each reduction (in general) requires a 122-by-61 bit division. In egcd, after it gets going nothing exceeds 61 bits, and across iterations the inputs to the division step get smaller each time around. So, e.g., when Raymond tried a Fraction with denominator 5813, "almost all" the egcd divisions involved inputs each with a single internal Python "digit". But "almost all" the raise-to-the-(P-2) divisions involve a numerator with 5 internal digts and 3 in the denominator. Big difference, even if the total number of divisions is about the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 15:19:43 2019 From: report at bugs.python.org (Abhilash Raj) Date: Thu, 15 Aug 2019 19:19:43 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1565896783.83.0.604311302558.issue34155@roundup.psfhosted.org> Abhilash Raj added the comment: @Victor: This is already backported to 3.6. I am not sure about what gets backported to 3.5 right now, I don't even see a 'Backport to 3.5' label on Github (which made me think we are discouraged to backport to 3.5). I can work on a manual backport if needed? This patch most probably won't backport to 2.7 without re-writing it completely since the implementation in 2.7 is much different than what we have today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 15:30:36 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Thu, 15 Aug 2019 19:30:36 +0000 Subject: [issue37866] PyModule_GetState Segmentation fault when called Py_Initialize In-Reply-To: <1565862147.92.0.832286772909.issue37866@roundup.psfhosted.org> Message-ID: <1565897436.99.0.133273836824.issue37866@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- nosy: +eric.snow, ncoghlan, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 15:48:50 2019 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 15 Aug 2019 19:48:50 +0000 Subject: [issue37868] `is_dataclass` returns `True` if `getattr` always succeeds. In-Reply-To: <1565870535.54.0.93577990924.issue37868@roundup.psfhosted.org> Message-ID: <1565898530.72.0.61970899051.issue37868@roundup.psfhosted.org> Eric V. Smith added the comment: I'm guessing I'm looking up the attribute on the instance, not the class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 15:49:46 2019 From: report at bugs.python.org (Anthony Sottile) Date: Thu, 15 Aug 2019 19:49:46 +0000 Subject: [issue20490] Show clear error message on circular import In-Reply-To: <1391367888.31.0.501253544651.issue20490@psf.upfronthosting.co.za> Message-ID: <1565898586.43.0.467373830728.issue20490@roundup.psfhosted.org> Change by Anthony Sottile : ---------- keywords: +patch pull_requests: +15028 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15308 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 16:02:08 2019 From: report at bugs.python.org (Anthony Sottile) Date: Thu, 15 Aug 2019 20:02:08 +0000 Subject: [issue20490] Show clear error message on circular import In-Reply-To: <1391367888.31.0.501253544651.issue20490@psf.upfronthosting.co.za> Message-ID: <1565899328.3.0.390151014666.issue20490@roundup.psfhosted.org> Change by Anthony Sottile : ---------- nosy: +Anthony Sottile versions: +Python 3.8, Python 3.9 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 16:04:31 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 15 Aug 2019 20:04:31 +0000 Subject: [issue37868] `is_dataclass` returns `True` if `getattr` always succeeds. In-Reply-To: <1565870535.54.0.93577990924.issue37868@roundup.psfhosted.org> Message-ID: <1565899471.97.0.464982769005.issue37868@roundup.psfhosted.org> Serhiy Storchaka added the comment: I am not sure that it is good idea to accept a type and an instance, but if it is a goal, is_dataclass() should be defined as: def is_dataclass(obj): cls = obj if isinstance(obj, type) else type(obj) return hasattr(cls, _FIELDS) _is_dataclass_instance() should be changed too: def _is_dataclass_instance(obj): return hasattr(type(obj), _FIELDS) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 16:15:09 2019 From: report at bugs.python.org (Marco Paolini) Date: Thu, 15 Aug 2019 20:15:09 +0000 Subject: [issue37587] JSON loads performance improvement for long strings In-Reply-To: <1563028922.54.0.821649437171.issue37587@roundup.psfhosted.org> Message-ID: <1565900109.36.0.789299964238.issue37587@roundup.psfhosted.org> Marco Paolini added the comment: I also confirm Inada's patch further improves performance! All my previous benchmarks were done with gcc and PGO optimizations performed only with test_json task... maybe this explains the weird results? I tested the performance of new master 69f37bcb28d7cd78255828029f895958b5baf6ff with *all* PGO task reverting my original patch: iff --git a/Modules/_json.c b/Modules/_json.c index 112903ea57..9b63167276 100644 --- a/Modules/_json.c +++ b/Modules/_json.c @@ -442,7 +442,7 @@ scanstring_unicode(PyObject *pystr, Py_ssize_t end, int strict, Py_ssize_t *next if (d == '"' || d == '\\') { break; } - if (d <= 0x1f && strict) { + if (strict && d <= 0x1f) { raise_errmsg("Invalid control character at", pystr, next); goto bail; } ... and surprise... Mean +- std dev: [69f37bcb28d7cd78255828029f895958b5baf6ff] 5.29 us +- 0.07 us -> [69f37bcb28d7cd78255828029f895958b5baf6ff-patched] 5.11 us +- 0.03 us: 1.04x faster (-4%) should we revert my original patch entirely now? Or am I missing something? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 16:30:41 2019 From: report at bugs.python.org (Hansraj Das) Date: Thu, 15 Aug 2019 20:30:41 +0000 Subject: [issue37869] Compilation warning on GCC version 7.4.0-1ubuntu1~18.04.1 Message-ID: <1565901041.74.0.0939495038375.issue37869@roundup.psfhosted.org> New submission from Hansraj Das : I am facing below compilation warning on compilation python source: *********************************************************************** gcc -pthread -c -Wno-unused-result -Wsign-compare -g -Og -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initial izers -Werror=implicit-function-declaration -I./Include/internal -I. -I./Include -DPy_BUILD_CORE -o Objects/obmalloc.o Objects/obmalloc.c Objects/obmalloc.c: In function __PyObject_Malloc_: Objects/obmalloc.c:1646:16: warning: _ptr_ may be used uninitialized in this function [-Wmaybe-uninitialized] return ptr; ^~~ *********************************************************************** This is another thread having suggestions from Victor: https://github.com/python/cpython/pull/15293 ---------- components: Build files: warning-2019-08-15 01-15-06.png messages: 349824 nosy: hansrajdas, vstinner priority: normal pull_requests: 15029 severity: normal status: open title: Compilation warning on GCC version 7.4.0-1ubuntu1~18.04.1 type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file48546/warning-2019-08-15 01-15-06.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 16:41:17 2019 From: report at bugs.python.org (Marco Paolini) Date: Thu, 15 Aug 2019 20:41:17 +0000 Subject: [issue37587] JSON loads performance improvement for long strings In-Reply-To: <1563028922.54.0.821649437171.issue37587@roundup.psfhosted.org> Message-ID: <1565901677.03.0.333504513672.issue37587@roundup.psfhosted.org> Marco Paolini added the comment: also worth noting escape sequences for non-ascii characters are slower, even when encoded length is the same. python -m pyperf timeit -s 'import json;' -s 'c = "?"; s = json.dumps(c * (2**10 // len(json.dumps(c)) - 2))' 'json.loads(s)' -o nonascii2k.json python -m pyperf timeit -s 'import json;' -s 'c = "a"; s = json.dumps(c * (2**10 // len(json.dumps(c)) - 2))' 'json.loads(s)' -o ascii2k.json Mean +- std dev: [ascii2k] 2.59 us +- 0.04 us -> [nonascii2k] 9.98 us +- 0.12 us: 3.86x slower (+286%) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 16:46:05 2019 From: report at bugs.python.org (Marco Paolini) Date: Thu, 15 Aug 2019 20:46:05 +0000 Subject: [issue37587] JSON loads performance improvement for long strings In-Reply-To: <1563028922.54.0.821649437171.issue37587@roundup.psfhosted.org> Message-ID: <1565901965.1.0.442510159332.issue37587@roundup.psfhosted.org> Marco Paolini added the comment: ops sorry here's the right commands python -m pyperf timeit -s 'import json;' -s 'c = "a"; s = json.dumps(c * (2**10 // (len(json.dumps(c)) - 2)))' 'json.loads(s)' -o ascii2k.json python -m pyperf timeit -s 'import json;' -s 'c = "?"; s = json.dumps(c * (2**10 // (len(json.dumps(c)) - 2)))' 'json.loads(s)' -o nonascii2k.json Mean +- std dev: [ascii2k] 3.69 us +- 0.05 us -> [nonascii2k] 12.4 us +- 0.1 us: 3.35x slower (+235%) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 16:59:04 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 15 Aug 2019 20:59:04 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565902744.99.0.314319928238.issue37834@roundup.psfhosted.org> Steve Dower added the comment: > For example, if we've opened an HSM reparse point, we must reopen to let > the file-system filter driver implement its semantics to replace the > reparse point with the real file from auxiliary storage and complete the > request. That is the stat() result I want when I say stat(filename, > follow_symlinks=False) or lstat(filename), because this file is not a > symlink. It's implicitly just the file to end users -- despite whatever > backend tricks are being played in the kernel to implement other > behavior such as HSM. Conflating this with a symlink is not right. Lies > catch up with us. We can't copy it as link via os.symlink and > os.readlink, and it doesn't get treated like a symlink in API functions. Okay, I get it now. So we _do_ want to "upgrade" lstat() to stat() when it's not a symlink. > If you want to add an "open reparse point" parameter ... I don't want to add any parameters - I want to have predictable and reasonable default behaviour. os.readlink() already exists for "open reparse point" behaviour. The discussion is only about what os.lstat() returns when you pass in a path to a junction. > As to mount points, yes, I do think we should always traverse them. > Please see my extended comment and the follow-up example on GitHub. I'm still not convinced that this is what we want to do. I don't have a true Linux machine handy to try it out (Python 3.6 and 3.7 on WSL behave exactly like the semantics I'm proposing, but that may just be because it's the Windows kernel below it). > A mount point is not a link. ismount() and islink() can never both be > true. Also, a POSIX symlink can never be a directory, which is why we > make stat() pretend directory symlinks aren't directories. If the user > wants a link, they can use a symlink that's created by os.symlink, > mklink, new-item -type SymbolicLink, etc. ismount() is currently not true for junctions. And I can't find any reference that says that POSIX symlinks can't point to directories, nor any evidence that we suppress symlink-to-directory creation or resolution in Python (also tested on WSL).. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 17:19:36 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Thu, 15 Aug 2019 21:19:36 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565903976.02.0.407911479563.issue29535@roundup.psfhosted.org> Ashwin Ramaswami added the comment: > Making the numeric hash non-predictable while maintaining its current properties would be difficult. Why so? > In fact, I think it's reasonable to assume that there are no websites vulnerable to a DOS via *numeric* hash collisions until we see evidence otherwise. I'd expect that there are *way* more places where a dict is being constructed with string keys in this way than with numeric keys. That's true, but why do we restrict ourselves to websites? This is how I see it: As a Python developer, it seems like my program is immune to hash collision DoS if I use strings/bytes as dictionary keys, but *not* if my keys, say, are tuples of strings. Why not make the hash non-predictable for all builtin types by default? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 17:28:20 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 15 Aug 2019 21:28:20 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565904500.2.0.000384809608634.issue37834@roundup.psfhosted.org> Steve Dower added the comment: > So we _do_ want to "upgrade" lstat() to stat() when it's not a symlink. Except this bug came about because we want to _downgrade_ stat() to lstat() when it's an appexeclink, because the whole point of those is to use them without following them (and yeah, most operations are going to fail, but they'd fail against the target file too). So we have this logic: def xstat(path, traverse): f = open(path, flags | (0 if traverse else OPEN_REPARSE_POINT)) if !f: # Special case for appexeclink if traverse and ERROR_CANT_OPEN_FILE: st = xstat(path, !traverse) if st.reparse_tag == APPEXECLINC: return st raise ERROR_CANT_OPEN_FILE # Handle "likely" errors if ERROR_ACCESS_DENIED or SHARING_VIOLATION: st = read_from_dir(os.path.split(path)) else: st = read_from_file(f) # Always make the OS resolve "unknown" reparse points ALLOWED_TO_TRAVERSE = {SYMLINK, MOUNT_POINT} if !traverse and st.reparse_tag not in ALLOWED_TO_TRAVERSE: return xstat(path, !traverse) return st And the open question is just whether MOUNT_POINT should be in that set near the end. I believe it should, since the alternative is to force all Python developers to write special Windows-only code to handle directory junctions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 17:34:36 2019 From: report at bugs.python.org (Marco Paolini) Date: Thu, 15 Aug 2019 21:34:36 +0000 Subject: [issue37587] JSON loads performance improvement for long strings In-Reply-To: <1563028922.54.0.821649437171.issue37587@roundup.psfhosted.org> Message-ID: <1565904876.38.0.453550450118.issue37587@roundup.psfhosted.org> Marco Paolini added the comment: ujson (https://github.com/esnme/ultrajson) instead is faster when decoding non-ascii in the same example above, so it is likely there is room for improvement... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 17:48:34 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 15 Aug 2019 21:48:34 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565905714.51.0.712455600857.issue37834@roundup.psfhosted.org> Steve Dower added the comment: So for an actual non-root mount point, ntpath.ismount() returns True and with IO_REPARSE_TAG_MOUNT_POINT included ntpath.islink() also returns True. nt.readlink() returns the "\\?\Volume{GUID}\" path Root mount points ("C:\\", etc.) do not return true for islink() os.rename() and os.unlink() work on non-root mount points, but not on root mount points. So there is at least some value in being able to detect "this is a root mount point that acts like a file". I'm not seeing why having both islink() and ismount() be true in this case is a problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 17:53:44 2019 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 15 Aug 2019 21:53:44 +0000 Subject: [issue37868] `is_dataclass` returns `True` if `getattr` always succeeds. In-Reply-To: <1565870535.54.0.93577990924.issue37868@roundup.psfhosted.org> Message-ID: <1565906024.7.0.800475712896.issue37868@roundup.psfhosted.org> Eric V. Smith added the comment: Yeah, I agree it's not an awesome design to work with classes or instances, but it's documented that way. As soon as I write some tests I'll check this in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 19:08:33 2019 From: report at bugs.python.org (Matt Christopher) Date: Thu, 15 Aug 2019 23:08:33 +0000 Subject: [issue37870] os.path.ismount returns false for disconnected CIFS mounts in Linux Message-ID: <1565910513.41.0.618173477068.issue37870@roundup.psfhosted.org> New submission from Matt Christopher : I've got a case where we mount a CIFS filesystem and then later the actual backing filesystem is deleted (but the mount remains on the machine). When running from a shell, this is the behavior which I see after the backing CIFS filesystem has gone away: root at 1b20608623a246f1af69058acdfbfd30000006:/fsmounts# ll ls: cannot access 'cifsmountpoint': Input/output error total 8 drwxrwx--- 3 _user _grp 4096 Aug 15 15:46 ./ drwxrwx--- 8 _user _grp 4096 Aug 15 15:46 ../ d????????? ? ? ? ? ? cifsmountpoint/ root at 1b20608623a246f1af69058acdfbfd30000006:/fsmounts# stat -c "%d" cifsmountpoint stat: cannot stat 'cifsmountpoint': Input/output error Running mount -l shows this: ///c7e868cd-3047-4881-b05b-a1a1d087dbf5 on /fsmounts/cifsmountpoint type cifs (rw,relatime,vers=3.0,cache=strict,username=,domain=,uid=0,noforceuid,gid=0,noforcegid,addr=52.239.160.104,file_mode=0777,dir_mode=0777,soft,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1) In the Python code that I see posixpath.py has this snippet: try: s1 = os.lstat(path) except (OSError, ValueError): # It doesn't exist -- so not a mount point. :-) return False The problem is that the comment: "# It doesn't exist -- so not a mount point. :-)" assumes a particular kind of OSError - in reality not every OS error means that it doesn't exist. In this case we're getting OSError with errno == 5, which is: OSError: [Errno 5] Input/output error: Now, I'm not entirely sure what (if anything) the ismount function is supposed to be doing here... but returning false seems incorrect. This IS a mount, and you can see so via mount -l. I am aware that there are other libraries (i.e. psutil.disk_partitions) which can help me to detect this situation but I was surprised that ismount was saying false here. It seems like it should possibly just raise, or maybe there's a fancy way to check mounts if lstat fails. This looks kinda related to https://bugs.python.org/issue2466 (although this is already fixed and not exactly the same problem it's a similar class of issue) ---------- messages: 349833 nosy: Matt Christopher priority: normal severity: normal status: open title: os.path.ismount returns false for disconnected CIFS mounts in Linux type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 19:38:49 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 15 Aug 2019 23:38:49 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565912328.99.0.254205143899.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > Okay, I get it now. So we _do_ want to "upgrade" lstat() to stat() > when it's not a symlink. I don't see that as a behavior upgrade. It's just an implementation detail. lstat() is still following its mandate to not follow symlinks -- however you ultimately define what a "symlink" is in this context in Windows. > I don't want to add any parameters - I want to have predictable and > reasonable default behaviour. os.readlink() already exists for > "open reparse point" behaviour. I'd appreciate a parameter to always open reparse points, even if a filter-driver or the I/O manager handles them. I'm no longer a big fan of mapping "follow_symlinks" to name surrogates (I used to like this idea a couple years ago), or splitting hairs regarding volume-mount-point junctions and bind-like junctions (used to like this too a year ago, because some projects do this, before I thought about the deeper concerns). But it's not up to me. If follow_symlinks means name surrogates, at least then lstat can open any reparse point that claims to link to another path and thus *should* have link-like behavior (hard link or soft link). For example, we are able to move, rename, and delete symlinks and junctions without affecting the target (except for a junction that's a volume mount point, Windows will try DeleteVolumeMountPointW, which can have side effects; failure is ignored and the directory deleted anyway). This is implemented by the Windows API opening the reparse point and checking for symlink and junction tags. It reparses other tags, regardless of whether they're name surrogates, but I assume name-surrogate reparse points should be implemented by their owning filter drivers to behave in a similar fashion for actions such as rename and delete. While deleting a name-surrogate reparse point should have no effect on the target, it still might have unintended consequences. For example, it might revive a 'deleted' file in a VFS for Git repo if we delete the tombstone reparse point that marks a file that's supposed to be 'deleted'. This might happen if code checks os.lstat(filename) and decides to delete the file in a non-standard way that ensures only a reparse point is deleted, e.g. CreateFileW(filename, ..., FILE_FLAG_DELETE_ON_CLOSE | FILE_FLAG_OPEN_REPARSE_POINT, NULL), or manually setting the FileDispositionInfo. (DeleteFileW would fail with a file-not-found error because it would reparse the tombstone.) Now it's in for a surprise because the file exists again in the projected filesystem, even though it was just 'deleted'. This is in theory. I haven't experimented with projected file systems to determine whether they actually allow opening a tombstone reparse point when using FILE_FLAG_OPEN_REPARSE_POINT. I assume they do, like any other reparse point, unless there's deeper magic involved here. The questions for me are whether os.readlink() should also read junctions and exactly what follow_symlinks means in Windows. We have a complicated story to tell if follow_symlinks=False (lstat) opens any reparse point or opens just name-surrogate reparse points, and islink() is made consistent with this, but then readlink() doesn't work. If junctions are handled as symlinks, then islink(), readlink(), symlink() would be used to copy a junction 'link' while copying a tree (e.g. shutil.copytree with symlinks=True). This would transform junctions into directory symlinks. In this case, we potentially have a problem that relative symlinks in the tree no longer target the same files when accessed via a directory symlink instead of a junction. No one thinks about this problem on the POSIX side because it would be weird to copy a mountpoint as a symlink. In POSIX, a mountpoint is always seen as just a directory and always traversed. > I'm still not convinced that this is what we want to do. I don't > have a true Linux machine handy to try it out (Python 3.6 and 3.7 on > WSL behave exactly like the semantics I'm proposing, but that may > just be because it's the Windows kernel below it). If you're accessing NT junctions under WSL, in that environment they're always handled as symlinks. And the result of my "C:/Junction" and "C:/Symlink" example --- i.e. "/mnt/c/Junction" and "/mnt/c/Symlink" -- is that *both* behave the same way, which is as expected since the WSL environment sees both as symlinks, but also fundamentally wrong. In an NT process, they behave differently, as a mount point (hard name grafting) and a symlink (soft name grafting). This is a decision in WSL's drvfs file-system driver, and I have to assume it's intentional. In a perfect world, a path on the volume should be consistently evaluated, regardless of whether it's accessed from a WSL or NT process. But it's also a difficult problem, maybe intractable, if they want to avoid Linux programs traversing junctions in dangerous operations -- e.g. `rm -rf`. The only name surrogate that POSIX programs know about is a symlink (so simple). I can see why they chose to handle junctions as symlinks, as a conservative, safe option, even if it leads to inconsistencies. > ismount() is currently not true for junctions. And I can't find any > reference that says that POSIX symlinks can't point to directories, Our current implementation for junctions is based on GetVolumePathNameW, which will be true for junctions that use the "Volume{...}" name to mount the file-system root directory. That's a volume mount point. I don't know why someone decided that's the sum total of "mount point" in Windows. DOS drives and UNC drives can refer to arbitrary file system directories. They don't have to refer to file-system root directory. We can have "W:" -> "\\??\\C:\\Windows", etc. Per the docs, a mount point for ismount() is a "point in a file system where a different file system has been mounted". The mounted directory doesn't have to be the root directory of the file system. I'd relax this definition to include all "hard" name grafting links to other directories, even within the same file system. What matter to me is the semantics of how this differs from the soft name grafting of a symlink. Note that GetVolumePathNameW is expensive and has bugs with subst drives, which we're not able to avoid unless someone happens to check the drive root directory, i.e. "W:/". It will claim that "W:/System32" is a volume path if "W:" is a subst drive for "C:/Windows". It also has a bug that a drive root is a mount point, even if the drive doesn't exist. Also, it's wrong in not checking for junctions in UNC paths. SMB supports opening reparse points over the wire. If follow_symlinks=False applies to name surrogates, then a junction would be detectable via os.lstat(filename).st_reparse_tag, which is not only much cheaper than GetVolumePathNameW, but also more generally correct and consistent with DOS and UNC drive mount points. > nor any evidence that we suppress symlink-to-directory creation or > resolution in Python (also tested on WSL).. S_IFDIR is suppressed for directory symlinks in the stat result. But os.path.isdir() is supposed to be based on os.stat, and thus follows symlinks. To that end, our nt._isdir is broken because it assumes GetFileAttributesW is sufficient. Since we're supposed to follow links, it's not working right for link targets that don't exist. It should return False in that case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 19:46:10 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 15 Aug 2019 23:46:10 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565912770.48.0.732266030891.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > It also has a bug that a drive root is a mount point, even if the > drive doesn't exist. Also, it's wrong in not checking for junctions > in UNC paths. SMB supports opening reparse points over the wire. "It" in the above sentences is ntpath.ismount, not GetVolumePathNameW. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 19:57:57 2019 From: report at bugs.python.org (Tim Peters) Date: Thu, 15 Aug 2019 23:57:57 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1565913477.09.0.712187957974.issue37863@roundup.psfhosted.org> Tim Peters added the comment: Mark, I did just a little browsing on this. It seems it's well known that egcd beats straightforward exponentiation for this purpose in arbitrary precision contexts, for reasons already sketched (egcd needs narrower arithmetic from the start, benefits from the division narrowing on each iteration, and since the quotient on each iteration usually fits in a single "digit" the multiplication by the quotient goes fast too). But gonzo implementations switch back to exponentiation, using fancier primitives like Montgomery multiplication. As usual, I'm not keen on bloating the code for "state of the art" giant int algorithms, but suit yourself! The focus in this PR is dead simple spelling changes with relatively massive payoffs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 20:34:52 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 16 Aug 2019 00:34:52 +0000 Subject: [issue37852] Pickling doesn't work for name-mangled private methods In-Reply-To: <1565801916.64.0.686845199304.issue37852@roundup.psfhosted.org> Message-ID: <1565915692.14.0.573042229515.issue37852@roundup.psfhosted.org> Change by Josh Rosenberg : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Objects referencing private-mangled names do not roundtrip properly under pickling. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 20:36:04 2019 From: report at bugs.python.org (ANdy) Date: Fri, 16 Aug 2019 00:36:04 +0000 Subject: =?utf-8?q?=5Bissue37871=5D_40_*_473_grid_of_=22=C3=A9=22_has_a_single_wro?= =?utf-8?q?ng_character_on_Windows?= Message-ID: <1565915764.5.0.613301280158.issue37871@roundup.psfhosted.org> New submission from ANdy : # To reproduce: # Put this text in a file `a.py` and run `py a.py`. # Or just run: py -c "print(('?' * 40 + '\n') * 473)" # Scroll up for a while. One of the lines will be: # ????????????????????????????????????????? # (You can spot this because it's slightly longer than the other lines.) # The error is consistently on line 237, column 21 (1-indexed). # The error reproduces on Windows but not Linux. Tested in both powershell and CMD. # (Failed to reproduce on either a real Linux machine or on Ubuntu with WSL.) # On Windows, the error reproduces every time consistently. # There is no error if N = 472 or 474. N = 473 # There is no error if W = 39 or 41. # (I tested with console windows of varying sizes, all well over 40 characters.) W = 40 # There is no error if ch = "e" with no accent. # There is still an error for other unicode characters like "?" or "?". ch = "?" # There is no error without newlines. s = (ch * W + "\n") * N # Assert the string itself is correct. assert all(c in (ch, "\n") for c in s) print(s) # There is no error if we use N separate print statements # instead of printing a single string with N newlines. # Similar scripts written in Groovy, JS and Ruby have no error. # Groovy: System.out.println(("?" * 40 + "\n") * 473) # JS: console.log(("?".repeat(40) + "\n").repeat(473)) # Ruby: puts(("?" * 40 + "\n") * 473) ---------- components: Windows messages: 349837 nosy: anhans, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: 40 * 473 grid of "?" has a single wrong character on Windows type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 20:36:40 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 16 Aug 2019 00:36:40 +0000 Subject: [issue33007] Objects referencing private-mangled names do not roundtrip properly under pickling. In-Reply-To: <1520314612.17.0.467229070634.issue33007@psf.upfronthosting.co.za> Message-ID: <1565915800.95.0.840700233239.issue33007@roundup.psfhosted.org> Josh Rosenberg added the comment: This problem is specific to private methods AFAICT, since they're the only things which have an unmangled __name__ used to pickle them, but are stored as a mangled name. More details on cause and solution on issue #37852, which I closed as a duplicate of this issue. ---------- nosy: +josh.r versions: +Python 3.6, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 20:47:15 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 16 Aug 2019 00:47:15 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565916435.22.0.601927911849.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > # Always make the OS resolve "unknown" reparse points > ALLOWED_TO_TRAVERSE = {SYMLINK, MOUNT_POINT} > if !traverse and st.reparse_tag not in ALLOWED_TO_TRAVERSE: > return xstat(path, !traverse) To me the naming here makes sense as ALLOWED_TO_OPEN -- as in if traverse is false, meaning we opened the tag, but the tag is not in ALLOWED_TO_OPEN, then we have to reopen in order to traverse it. But then, on the second pass after ERROR_CANT_ACCESS_FILE, traverse is false, so we would also have to special case tags that should never be traversed in NOT_ALLOWED_TO_TRAVERSE = {APPEXECLINK, ...}. I mentioned this in a GitHub comment, and suggested maybe adding another internal-only parameter to check to avoid having to ever special case the app-exec-link tag. For example, we could have an explicit "open_reparse_point" parameter. It would take precedence over traverse (i.e. follow_symlinks). For now, it could be internal only. I assumed stat() would return the reparse point for all tags that fail to reparse with ERROR_CANT_ACCESS_FILE since it's not an invalid reparse point, just an unhandled one that has no other significance at the file system level. To stat(), it can never be anything other than a reparse point. Whatever relevance it has depends on some other context (e.g. a CreateProcessW call). > And the open question is just whether MOUNT_POINT should be in that > set near the end. I believe it should, since the alternative is to > force all Python developers to write special Windows-only code to > handle directory junctions. Python provides no cross-platform tooling to manipulate mount points or read what they target (e.g. something like "/dev/sda1" in Unix), so that doesn't bother me per se. A mount point is just a directory in the POSIX mindset. That doesn't mean, however, that I wouldn't like the ability to detect "name surrogate" reparse points in general to implement safer behavior for shutil.rmtree and anything else that walks a directory tree. Windows shells don't follow name surrogates (including mount points) when deleting a tree, such as `rmdir /s`. Unix `rm -rf` does follow mount points. (A process would need root access to unmout a directory anyway.) The author's of shutil.rmtree have a Unix perspective. For Windows, I'd like to change that perspective. When in Rome... If the only way to get this is to special case mount-point or name-surrogate reparse points as applicable to "follow_symlinks", then I suggest that this should be clearly documented and that we not go so far as to pretend that they're symlinks via S_IFLNK, islink, and readlink. Continue reporting mount points as directories (S_IFDIR). Continue with only supporting actual symbolic links for the triple: islink(), readlink(), and symlink(). In this case, we can copy symlinks and be certain the semantics remain the same since we're not changing the type of reparse point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 21:27:05 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Fri, 16 Aug 2019 01:27:05 +0000 Subject: [issue17305] IDNA2008 encoding is missing In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za> Message-ID: <1565918825.22.0.233355719846.issue17305@roundup.psfhosted.org> Ashwin Ramaswami added the comment: So is the consensus that the best way to do this is to move the "idna" library to stdlib, or implement it from scratch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 22:48:33 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 16 Aug 2019 02:48:33 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565923713.73.0.412295061853.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > So for an actual non-root mount point ntpath.ismount() returns True > and with IO_REPARSE_TAG_MOUNT_POINT included ntpath.islink() also > returns True. nt.readlink() returns the "\\?\Volume{GUID}\" path If islink() is true, then st_mode has S_IFLNK and not S_IFDIR. So we have a mount point that's a symlink, which is not possible in POSIX, and it's not a directory, which is unusual in POSIX to say the least. For cross-platform consistency, I think it's better if ismount() is a directory. The question would be how to ensure that's true in all cases. Windows make this hard to accomplish reliably due to DOS 'devices' that get reparsed in the object manager to arbitrary paths, not necessarily to volume devices. > Root mount points ("C:\\", etc.) do not return true for islink() Not really. Here's a mountpoint-symlink chimera: >>> os.readlink('C:/Mount/Windows') 'C:\\Windows' >>> os.system('subst W: C:\\Mount\\Windows') 0 It's a symlink and not a directory: >>> os.path.islink('W:\\') True >>> os.lstat('W:\\').st_mode & stat.S_IFDIR 0 But it's also a mount point: >>> os.path.ismount('W:\\') True The object manager reparses "W:" as "\\??\\C:\\Mount\\Windows", and we open it with a trailing backlash, which is fine, i.e. "\\??\\C:\\Mount\\Windows\\". > I'm not seeing why having both islink() and ismount() be true > in this case is a problem. It's only possible if a mount point is not a directory. That we'd be returning this for a junction is a strange state of affairs because a junction must target a file system directory. I prefer generalizing junction as a name-surrogate type that allows S_IFDIR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 15 23:58:40 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 16 Aug 2019 03:58:40 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1565927920.22.0.783852243761.issue37863@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset f3cb68f2e4c3e0c405460f9bb881f5c1db70f535 by Raymond Hettinger in branch 'master': bpo-37863: Optimize Fraction.__hash__() (#15298) https://github.com/python/cpython/commit/f3cb68f2e4c3e0c405460f9bb881f5c1db70f535 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 00:00:13 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 16 Aug 2019 04:00:13 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1565928013.3.0.49565054311.issue37863@roundup.psfhosted.org> Raymond Hettinger added the comment: There's likely more that could be done -- I've just taken the low hanging fruit. If someone wants to re-open this and go farther, please take it from here. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 00:05:43 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 16 Aug 2019 04:05:43 +0000 Subject: =?utf-8?q?=5Bissue37871=5D_40_*_473_grid_of_=22=C3=A9=22_has_a_single_wro?= =?utf-8?q?ng_character_on_Windows?= In-Reply-To: <1565915764.5.0.613301280158.issue37871@roundup.psfhosted.org> Message-ID: <1565928343.08.0.0123288794152.issue37871@roundup.psfhosted.org> Eryk Sun added the comment: To be compatible with Windows 7, _io__WindowsConsoleIO_write_impl in Modules/_io/winconsoleio.c is forced to write to the console in chunks that do not exceed 32 KiB. It does so by repeatedly dividing the length to decode by 2 until the decoded buffer size is small enough. wlen = MultiByteToWideChar(CP_UTF8, 0, b->buf, len, NULL, 0); while (wlen > 32766 / sizeof(wchar_t)) { len /= 2; wlen = MultiByteToWideChar(CP_UTF8, 0, b->buf, len, NULL, 0); } With `('?' * 40 + '\n') * 473`, encoded as UTF-8, we have 473 82-byte lines (note that "\n" has been translated to "\r\n"). This is 38,786 bytes, which is too much for a single write, so it splits it in two. >>> 38786 // 2 19393 >>> 19393 // 82 236 >>> 19393 % 82 41 This means line 237 ends up with 20 '?' characters (UTF-8 b'\xc3\xa9') and one partial character sequjence, b'\xc3'. When this buffer is passed to MultiByteToWideChar to decode from UTF-8 to UTF-16, the partial sequence gets decoded as the replacement character U+FFFD. For the next write, the remaining b'\xa9' byte also gets decoded as U+FFFD. To avoid this, _io__WindowsConsoleIO_write_impl could decode the whole buffer in one pass, and slice that up into writes that are less than 32 KiB. Or it could ensure that its UTF-8 slices are always at character boundaries. ---------- components: +IO nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 00:43:40 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 16 Aug 2019 04:43:40 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1565930620.42.0.371969220185.issue37824@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- nosy: +rhettinger, taleinat title: IDLE: DeprecationWarning not handled properly -> IDLE: Handle Shell input warnings properly. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 01:23:48 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 16 Aug 2019 05:23:48 +0000 Subject: [issue34857] IDLE: Module warnings misplaced. In-Reply-To: <1538338230.46.0.545547206417.issue34857@psf.upfronthosting.co.za> Message-ID: <1565933028.43.0.481335102077.issue34857@roundup.psfhosted.org> Terry J. Reedy added the comment: I moved leaving SyntaxWarnings as warnings to #37824, as that is mostly about editing pyshell. Changing the ordering of warnings and RESTART involves run.show_warnings. I believe the latter should collect lines in a warnings list and print ''.join(warnings) at the appropriate time. ---------- title: IDLE: SyntaxWarning not handled properly -> IDLE: Module warnings misplaced. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 01:42:25 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 16 Aug 2019 05:42:25 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1565934145.46.0.453842034537.issue37824@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- keywords: +patch pull_requests: +15030 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15311 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 01:50:48 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 16 Aug 2019 05:50:48 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1565934648.0.0.367299848361.issue37824@roundup.psfhosted.org> Terry J. Reedy added the comment: I am combining the trivial 'leave Shell input SyntaxWarnings alone (instead of making them SyntaxErrors)' part of #34857 with this issue, 'print Shell input (and the very rare internal IDLE Warnings occurring after Shell exists) in Shell, and changing the title accordingly. The PR is a WIP with at least two bugs. Help wanted. 1. the triple output. (Before the patch, when I started IDLE from command prompt, I only saw one. 2. Warnings are inserted before the text generating the warning. I interpret this as intercepted \n causing compilation and printing of the warning before the \n is inserted at the end of the line and the iomark moved to the beginning of the next. I don't know what moves the iomark. ---------- stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 01:55:46 2019 From: report at bugs.python.org (Abhilash Raj) Date: Fri, 16 Aug 2019 05:55:46 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565934946.3.0.516174976589.issue37764@roundup.psfhosted.org> Abhilash Raj added the comment: You have correctly identified that "=aa" is detected as a encoded word and causes the get_encoded_word to fail. However, "=?utf-8?q?somevalue?=aa" should ideally get parsed as "somevalueaa" and not "=?utf-8?q?somevalue?=aa". This is because "=?utf-8?q?somevalue?=" is a valid encoded word, it is just not followed by an empty whitespace. modified Lib/email/_header_value_parser.py @@ -1037,7 +1037,10 @@ def get_encoded_word(value): raise errors.HeaderParseError( "expected encoded word but found {}".format(value)) remstr = ''.join(remainder) - if len(remstr) > 1 and remstr[0] in hexdigits and remstr[1] in hexdigits: + if (len(remstr) > 1 and + remstr[0] in hexdigits and + remstr[1] in hexdigits and + tok.count('?') < 2): # The ? after the CTE was followed by an encoded word escape (=XX). rest, *remainder = remstr.split('?=', 1) This can be avoided by checking `?` occurs twice in the `tok`. The 2nd bug, which needs a better test case, is that if the encoded_word is invalid, you will keep running into infinite loop, which you correctly fixed in your PR. However, the test case you used is more appropriate for the first issue. You can fix both the issues, for which, you need to add a test case for 2nd issue and fix for the first issue. Looking into the PR now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 01:58:50 2019 From: report at bugs.python.org (Abhilash Raj) Date: Fri, 16 Aug 2019 05:58:50 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565935130.26.0.088698805988.issue37764@roundup.psfhosted.org> Abhilash Raj added the comment: I meant, =aa is identified as encoded word escape ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 02:05:33 2019 From: report at bugs.python.org (Abhilash Raj) Date: Fri, 16 Aug 2019 06:05:33 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1565935533.32.0.461471235183.issue37764@roundup.psfhosted.org> Abhilash Raj added the comment: Although, the 2nd bug I spoke of is kind of speculative, I haven't been able to find a test case which matches rfc2047_matcher but raises exception with get_encoded_word (after, ofcourse, the first bug is fixed), which the only way to cause an infinite loop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 04:27:39 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 16 Aug 2019 08:27:39 +0000 Subject: [issue37256] urllib.request.Request documentation erroneously refers to the "final two" In-Reply-To: <1560366755.97.0.221740241329.issue37256@roundup.psfhosted.org> Message-ID: <1565944059.1.0.563869481969.issue37256@roundup.psfhosted.org> miss-islington added the comment: New changeset f9919121460bffc04f935dbdb85f0af3ffbd3ddf by Miss Islington (bot) in branch '3.8': bpo-37256: Wording in Request class docs (GH-14792) https://github.com/python/cpython/commit/f9919121460bffc04f935dbdb85f0af3ffbd3ddf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 04:28:18 2019 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 16 Aug 2019 08:28:18 +0000 Subject: [issue37256] urllib.request.Request documentation erroneously refers to the "final two" In-Reply-To: <1560366755.97.0.221740241329.issue37256@roundup.psfhosted.org> Message-ID: <1565944098.81.0.338065431622.issue37256@roundup.psfhosted.org> Senthil Kumaran added the comment: Thank you for the patch, CuriousLearner. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 04:45:17 2019 From: report at bugs.python.org (Vinay Sharma) Date: Fri, 16 Aug 2019 08:45:17 +0000 Subject: [issue37703] Inconsistent gather with child exception In-Reply-To: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org> Message-ID: <1565945117.48.0.126596313518.issue37703@roundup.psfhosted.org> Vinay Sharma added the comment: Hi Dimitri, You are right, gather.cancel() doesn't work once it has propagated an exception. This happens because after propagating the exception to the caller, gather is marked as done. And cancel doesn't work after a Future object has been marked done. You can test the same by printing the return value of gather.cancel(). It will be False I also believe that the documentation of gather should explicitly mention this. But, depending on the fact, whether this is an expected behaviour, current code base might also need changes. Therefore I have created two patches, one updating the current documentation according to the current functionality, and other changing the codebase which supports cancelling even after raising exceptions. I will try to contact one of the core developers on deciding which one is the way to go. ---------- keywords: +patch nosy: +vinay0410 Added file: https://bugs.python.org/file48547/gather_cancel_doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 04:46:08 2019 From: report at bugs.python.org (Vinay Sharma) Date: Fri, 16 Aug 2019 08:46:08 +0000 Subject: [issue37703] Inconsistent gather with child exception In-Reply-To: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org> Message-ID: <1565945168.35.0.697748634833.issue37703@roundup.psfhosted.org> Change by Vinay Sharma : Added file: https://bugs.python.org/file48548/gather_cancel_code.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 04:54:42 2019 From: report at bugs.python.org (Mark Dickinson) Date: Fri, 16 Aug 2019 08:54:42 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565945682.51.0.189873766497.issue29535@roundup.psfhosted.org> Mark Dickinson added the comment: > Why so? Python's hash needs to obey the invariant that `hash(x) == hash(y)` for any two hashable objects with `x == y`. That makes life particularly hard for numeric types, because there are a number of *different* numeric types where equality can hold across those types. This includes not just built-in types, but third party types as well (think of NumPy, gmpy2, SymPy, and other libraries providing numbers that need to compare equal to Python numbers with the same value). So for example, `hash(1.5)`, `hash(Decimal("1.5"))`, `hash(Fraction(3, 2))`, `hash(1.5 + 0j)`, `hash(numpy.float32(1.5))`, `hash(bigfloat.BigFloat(1.5, precision=200))` must _all_ be equal to one another within a single running Python process. Moreover, hash computation needs to be efficient for common types like floats and integers, while also not being impossibly slow for other types. (Early versions of Decimal's hash did a check to see whether the Decimal instance was an exact integer, and if so, converted that Decimal instance to an integer before taking its hash. But doing that with `Decimal(1e999999)` doesn't go well.) It would definitely be *possible* to: - compute a hash in a cross-type-compatible way - do some sort of uniform post-processing of that hash, incorporating information from a per-process random salt The operations described by Melissa O'Neill in her PCG paper give ideas for some ways to do such post-processing: regard the hash and the salt as together forming a 128-bit integer, and then collapse that 128-integer down to a 64-bit integer using one of the PCG post-processing methods. Note that as far as I know there's been no validation of those methods from a cryptographic (rather than a statistical) perspective. However, it would be significant work, be disruptive not just to CPython, but to 3rd party packages and to other Python implementations, would slow down common hashing operations, and would increase the amount and the complexity of code that has to be maintained into the future. So there's no shortage of reasons *not* to change the numeric hash. What I think we're lacking is a single reason *to* change it. Can you give a plausible example of a situation where the predictability of the numeric hash can lead to possible security issues? See also the recent issue #37807. > but *not* if my keys, say, are tuples of strings Bad example. :-) The hash of a tuple is based on the hash of its contents. So if those contents are strings, the tuple benefits from the string hash randomization. mirzakhani:~ mdickinson$ python -c "print(hash(('abc', 'def')))" -824966383135019564 mirzakhani:~ mdickinson$ python -c "print(hash(('abc', 'def')))" -5971473524922642515 mirzakhani:~ mdickinson$ python -c "print(hash(('abc', 'def')))" 5384650403450490974 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 06:41:33 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 16 Aug 2019 10:41:33 +0000 Subject: [issue37540] vectorcall: keyword names must be strings In-Reply-To: <1562746011.67.0.0539270871483.issue37540@roundup.psfhosted.org> Message-ID: <1565952092.99.0.207918091408.issue37540@roundup.psfhosted.org> miss-islington added the comment: New changeset 0567786d26348aa7eaf0ab1b5d038fdabe409d92 by Miss Islington (bot) (Jeroen Demeyer) in branch 'master': bpo-37540: vectorcall: keyword names must be strings (GH-14682) https://github.com/python/cpython/commit/0567786d26348aa7eaf0ab1b5d038fdabe409d92 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 07:55:40 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 16 Aug 2019 11:55:40 +0000 Subject: [issue17305] IDNA2008 encoding is missing In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za> Message-ID: <1565956540.28.0.925353257987.issue17305@roundup.psfhosted.org> Andrew Svetlov added the comment: There is no consensus yet, IMHO. There is a lack of resources for the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 08:02:40 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 16 Aug 2019 12:02:40 +0000 Subject: [issue37703] Inconsistent gather with child exception In-Reply-To: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org> Message-ID: <1565956960.12.0.667365361726.issue37703@roundup.psfhosted.org> Andrew Svetlov added the comment: The behavior change is not backward compatible, we cannot apply it. Also, please use github pull requests for proposing a patch: https://devguide.python.org/pullrequest/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 08:15:11 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Fri, 16 Aug 2019 12:15:11 +0000 Subject: [issue37540] vectorcall: keyword names must be strings In-Reply-To: <1562746011.67.0.0539270871483.issue37540@roundup.psfhosted.org> Message-ID: <1565957711.76.0.174139882214.issue37540@roundup.psfhosted.org> Change by Jeroen Demeyer : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 08:33:05 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 16 Aug 2019 12:33:05 +0000 Subject: [issue37790] subprocess.Popen() is extremely slow In-Reply-To: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org> Message-ID: <1565958785.75.0.706336579509.issue37790@roundup.psfhosted.org> Antoine Pitrou added the comment: Can you post a simple script showcasing the performance degradation? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 09:09:26 2019 From: report at bugs.python.org (Tal Einat) Date: Fri, 16 Aug 2019 13:09:26 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1565960966.69.0.0774852010105.issue37824@roundup.psfhosted.org> Tal Einat added the comment: Il take a look at this. I've very recently gone through the relevant parts of the code and I should be able to figure it it efficiently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 09:21:10 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 16 Aug 2019 13:21:10 +0000 Subject: [issue37872] Move statitics in Python/import.c to top of the file Message-ID: <1565961670.68.0.815730473417.issue37872@roundup.psfhosted.org> New submission from Joannah Nanjekye : Following a PR review here: https://github.com/python/cpython/pull/15057 by @ericsnowcurrently i.e : Please move both these statics to the top of the file (next to CACHEDIR) as globals. To keep the diff in the above PR simple, I am tracking this refactor in this issue. ---------- assignee: nanjekyejoannah components: Library (Lib) messages: 349859 nosy: eric.snow, nanjekyejoannah, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Move statitics in Python/import.c to top of the file type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 09:23:11 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 16 Aug 2019 13:23:11 +0000 Subject: [issue37872] Move statitics in Python/import.c to top of the file In-Reply-To: <1565961670.68.0.815730473417.issue37872@roundup.psfhosted.org> Message-ID: <1565961791.0.0.986064453311.issue37872@roundup.psfhosted.org> Joannah Nanjekye added the comment: Relevant comment from @gnprice. I think it would be better to make that as a separate change. This style where they're block-local is the way the existing code works, which keeps the diff simple. It's also the way that every use of _Py_IDENTIFIER in this file works. So I think the cleanest way to change the style would be to sweep through this whole file (or more) in one PR, separate from any substantive changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 09:24:01 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 16 Aug 2019 13:24:01 +0000 Subject: [issue37872] Move statitics in Python/import.c to top of the file In-Reply-To: <1565961670.68.0.815730473417.issue37872@roundup.psfhosted.org> Message-ID: <1565961841.3.0.337603390668.issue37872@roundup.psfhosted.org> Joannah Nanjekye added the comment: Keeping this until the PR https://github.com/python/cpython/pull/15057 is merged. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 09:52:40 2019 From: report at bugs.python.org (Vinay Sharma) Date: Fri, 16 Aug 2019 13:52:40 +0000 Subject: [issue37703] Inconsistent gather with child exception In-Reply-To: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org> Message-ID: <1565963560.33.0.289198257842.issue37703@roundup.psfhosted.org> Change by Vinay Sharma : ---------- pull_requests: +15031 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15312 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 10:02:56 2019 From: report at bugs.python.org (Josh Rosenberg) Date: Fri, 16 Aug 2019 14:02:56 +0000 Subject: [issue37872] Move statics in Python/import.c to top of the file In-Reply-To: <1565961670.68.0.815730473417.issue37872@roundup.psfhosted.org> Message-ID: <1565964176.68.0.231198902653.issue37872@roundup.psfhosted.org> Change by Josh Rosenberg : ---------- title: Move statitics in Python/import.c to top of the file -> Move statics in Python/import.c to top of the file _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 10:03:06 2019 From: report at bugs.python.org (Vinay Sharma) Date: Fri, 16 Aug 2019 14:03:06 +0000 Subject: [issue37703] Inconsistent gather with child exception In-Reply-To: <1564390209.24.0.854284418154.issue37703@roundup.psfhosted.org> Message-ID: <1565964186.36.0.236329148717.issue37703@roundup.psfhosted.org> Vinay Sharma added the comment: Hi Andrew, Thanks for replying! I understand that the behavior change is not backward compatible. But the current behavior is a bit ambiguous ad mentioned by Dimitri, therefore I have updated the documentation and opened a Pull request. I would be very glad if you could review it. Thanks! Also, would adding an optional argument like force_cancel=False to ``gather.cancel``, which won't return even if gather is done be backward compatible. Should I open a PR with this change also, so that you can better review it and see if it looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 10:15:28 2019 From: report at bugs.python.org (D. A. Pellegrino) Date: Fri, 16 Aug 2019 14:15:28 +0000 Subject: [issue37873] unittest: execute tests in parallel Message-ID: <1565964928.02.0.804836557192.issue37873@roundup.psfhosted.org> New submission from D. A. Pellegrino : The unittest documentation makes reference to a potential parallelization feature: "Note that shared fixtures do not play well with [potential] features like test parallelization and they break test isolation. They should be used with care." (https://docs.python.org/3/library/unittest.html) However, it seems that executing tests in parallel is not yet a feature of unittest. This enhancement request is to add parallel execution of tests to unittest. A command line option may be a good interface. Ideally, it would be compatible with test discovery. Outside of the Python ecosystem, a common practice is to define test cases in a Makefile and then execute GNU Make with the '-j' flag (https://www.gnu.org/software/make/manual/html_node/Parallel.html#Parallel). Adding such an option to unittest would be a convenience and may save the effort of bringing in additional libraries or tools for parallel unit test execution. ---------- components: Library (Lib) messages: 349864 nosy: user93448 priority: normal severity: normal status: open title: unittest: execute tests in parallel type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 10:20:11 2019 From: report at bugs.python.org (Tim Peters) Date: Fri, 16 Aug 2019 14:20:11 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1565965211.34.0.594759949438.issue29535@roundup.psfhosted.org> Tim Peters added the comment: I'm with Mark: leave numeric hashes alone. There's no reason to change them, and in addition to what Mark wrote it's a positively Good Thing that `hash(i) == i` for all sufficiently small ints. Not only is that efficient to compute, it guarantees there are no collisions _at all_ in the common case of a dict indexed by a contiguous range of integers. The _purpose_ of `hash()` in Python isn't to create an illusion of randomness, it's to support efficient dicts and sets. Mucking with string hashes was a pragmatic hack to alleviate concerns about DOS attacks specific to string-indexed dicts. A better technical solution to that would have been to introduce a different flavor of dict with guaranteed good worst-case behaviors, but, pragmatically, a great many users would never realize that's what they really wanted, and it wouldn't have helped pre-existing code at all. But there's no reason to spread that hack beyond the use cases that needed it, and much reason not to. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 10:22:41 2019 From: report at bugs.python.org (af) Date: Fri, 16 Aug 2019 14:22:41 +0000 Subject: [issue37874] json traceback on a float Message-ID: <1565965361.29.0.137485852534.issue37874@roundup.psfhosted.org> New submission from af : json.loads traceback with: [In [16]: json.loads("[1.e-8]") --------------------------------------------------------------------------- JSONDecodeError Traceback (most recent call last) in () ----> 1 json.loads("[1.e-8]") /scr/fonari/2019-4/internal/lib/python3.6/json/__init__.py in loads(s, encoding, cls, object_hook, parse_float, parse_int, parse_constant, object_pairs_hook, **kw) 352 parse_int is None and parse_float is None and 353 parse_constant is None and object_pairs_hook is None and not kw): --> 354 return _default_decoder.decode(s) 355 if cls is None: 356 cls = JSONDecoder /scr/fonari/2019-4/internal/lib/python3.6/json/decoder.py in decode(self, s, _w) 337 338 """ --> 339 obj, end = self.raw_decode(s, idx=_w(s, 0).end()) 340 end = _w(s, end).end() 341 if end != len(s): /scr/fonari/2019-4/internal/lib/python3.6/json/decoder.py in raw_decode(self, s, idx) 353 """ 354 try: --> 355 obj, end = self.scan_once(s, idx) 356 except StopIteration as err: 357 raise JSONDecodeError("Expecting value", s, err.value) from None JSONDecodeError: Expecting ',' delimiter: line 1 column 3 (char 2) Works with json.loads("[1.0e-8]") and json.loads("[1e-8]") ---------- components: Library (Lib) messages: 349866 nosy: af priority: normal severity: normal status: open title: json traceback on a float type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 10:24:32 2019 From: report at bugs.python.org (af) Date: Fri, 16 Aug 2019 14:24:32 +0000 Subject: [issue37874] json traceback on a float In-Reply-To: <1565965361.29.0.137485852534.issue37874@roundup.psfhosted.org> Message-ID: <1565965472.97.0.650238001547.issue37874@roundup.psfhosted.org> Change by af : ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 10:29:06 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 16 Aug 2019 14:29:06 +0000 Subject: [issue37874] json traceback on a float In-Reply-To: <1565965361.29.0.137485852534.issue37874@roundup.psfhosted.org> Message-ID: <1565965746.76.0.478372185623.issue37874@roundup.psfhosted.org> Serhiy Storchaka added the comment: 1.0e-8 is not a format for numbers in JSON. See RFC 7159 (https://tools.ietf.org/html/rfc7159.html#section-6): number = [ minus ] int [ frac ] [ exp ] decimal-point = %x2E ; . digit1-9 = %x31-39 ; 1-9 e = %x65 / %x45 ; e E exp = e [ minus / plus ] 1*DIGIT frac = decimal-point 1*DIGIT int = zero / ( digit1-9 *DIGIT ) minus = %x2D ; - plus = %x2B ; + zero = %x30 ; 0 ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 10:52:10 2019 From: report at bugs.python.org (Sivaprabu Ganesan) Date: Fri, 16 Aug 2019 14:52:10 +0000 Subject: [issue37875] gzip module any difference for compressing png file in version 2.X and 3.X Message-ID: <1565967130.84.0.685308566342.issue37875@roundup.psfhosted.org> New submission from Sivaprabu Ganesan : gzip module any difference for compressing png file in version 2.X and 3.X ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 349868 nosy: Sivaprabu Ganesan, sjoerd priority: normal severity: normal status: open title: gzip module any difference for compressing png file in version 2.X and 3.X type: performance versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 11:02:19 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 16 Aug 2019 15:02:19 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1565967739.67.0.659637242288.issue37824@roundup.psfhosted.org> Terry J. Reedy added the comment: The triple (or double, see below) printing seems like a pure bug to be fixed. A fix could be a separate PR to be merged 'immediately'. But there is a complication with insertion location. My bug claim was based on a one line statement, where 'before' looks wrong and 'after', as in REPL, right. >>> Warning (from warnings module): # Printed 3 times, 2 deleted. File "", line 1 0 is 0 SyntaxWarning: "is" with a literal. Did you mean "=="? 0 is 0 True >>> 0 is 0 # REPL :1: SyntaxWarning: "is" with a literal. Did you mean "=="? True But now consider a more realistic compound statement. >>> if 0 is 0: # REPL ... print('true') ... :1: SyntaxWarning: "is" with a literal. Did you mean "=="? true With IDLE, a warning is printed *before* the user enters a blank line to signal end of statement. >>> Warning (from warnings module): # Only printed TWICE!. File "", line 1 if 0 is 0: SyntaxWarning: "is" with a literal. Did you mean "=="? if 0 is 0: print('true') |< cursor location A user could edit the condition, add more to the suite, or hit return. In the latter 2 cases, the warnings are repeated. In this case, the insertion seems like the best that can be done. Perhaps the msg349845 comment about run.show_warnings collecting warnings for possible delayed display applies to pyshell.show_warnings. Or the warning could be put in a popup, though I do not especially like the idea of that. Or it could be logged to a separate Warnings window, and a red "Warning logged' flashed on the status bar. I suspect that this case is why a fake prompt was previously tacked on to the end of the warning, though I also suspect these complications are why shell input warnings were relegated to a possibly non-existent console (where the fake prompt is nonsense). Behavior is the same with '\e' and DeprecationWarning. This example further convinces me that multiline shell input should be isolated from both prompts and intermixed outputs. I plan to open that issue later today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 11:09:12 2019 From: report at bugs.python.org (Zachary Ware) Date: Fri, 16 Aug 2019 15:09:12 +0000 Subject: [issue37875] gzip module any difference for compressing png file in version 2.X and 3.X In-Reply-To: <1565967130.84.0.685308566342.issue37875@roundup.psfhosted.org> Message-ID: <1565968152.19.0.44064166283.issue37875@roundup.psfhosted.org> Zachary Ware added the comment: Sorry, but your report is unclear. Are you asking if there is any difference, or are you reporting a difference? If the former, this is not the correct forum for such questions, please try python-list at python.org or StackOverflow instead. If the latter, you'll need to include sample code and data that shows the issue. ---------- components: -2to3 (2.x to 3.x conversion tool) nosy: +zach.ware type: performance -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 11:11:41 2019 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 16 Aug 2019 15:11:41 +0000 Subject: [issue37874] json traceback on a float In-Reply-To: <1565965361.29.0.137485852534.issue37874@roundup.psfhosted.org> Message-ID: <1565968301.5.0.114867957882.issue37874@roundup.psfhosted.org> Eric V. Smith added the comment: I think Serhiy means 1.e-8 is not valid. The spec says that at least one digit is required in the "frac" part, after the decimal. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 11:39:55 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 16 Aug 2019 15:39:55 +0000 Subject: =?utf-8?q?=5Bissue37871=5D_40_*_473_grid_of_=22=C3=A9=22_has_a_single_wro?= =?utf-8?q?ng_character_on_Windows?= In-Reply-To: <1565915764.5.0.613301280158.issue37871@roundup.psfhosted.org> Message-ID: <1565969995.13.0.0740308675526.issue37871@roundup.psfhosted.org> Steve Dower added the comment: I'd rather keep encoding incrementally, and reduce the length of each attempt until the last UTF-8 character does not have its top bit set (i.e. is the final character in a multi-byte sequence). Otherwise the people who like to print >2GB worth of data to the console will complain about the memory error :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 11:42:21 2019 From: report at bugs.python.org (af) Date: Fri, 16 Aug 2019 15:42:21 +0000 Subject: [issue37874] json traceback on a float In-Reply-To: <1565965361.29.0.137485852534.issue37874@roundup.psfhosted.org> Message-ID: <1565970141.09.0.36258349825.issue37874@roundup.psfhosted.org> af added the comment: I understand, thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 12:06:36 2019 From: report at bugs.python.org (Zeth) Date: Fri, 16 Aug 2019 16:06:36 +0000 Subject: [issue37876] Tests for Rot13 codec Message-ID: <1565971596.92.0.47171524836.issue37876@roundup.psfhosted.org> New submission from Zeth : Julius Caesar might have written the Rot13 codec, but he forgot to write unit tests, dragging down test coverage. ---------- components: Tests messages: 349874 nosy: zeth priority: normal pull_requests: 15033 severity: normal status: open title: Tests for Rot13 codec type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 12:31:04 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 16 Aug 2019 16:31:04 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565973064.24.0.103734698374.issue37834@roundup.psfhosted.org> Steve Dower added the comment: >> I don't want to add any parameters - I want to have predictable and >> reasonable default behaviour. os.readlink() already exists for >> "open reparse point" behaviour. > > I'd appreciate a parameter to always open reparse points, even if a > filter-driver or the I/O manager handles them. But that's only required if lstat() traverses junctions, which I'm not proposing to do. > I'm no longer a big fan of mapping "follow_symlinks" to name surrogates > ... But it's not up to me. If follow_symlinks means name surrogates, at > least then lstat can open any reparse point that claims to link to > another path and thus *should* have link-like behavior (hard link or > soft link). Yeah, ultimately it looks like it'll be up to me, which is why I want as much of your input as I can get before having to make a call :) I'm leaning towards "if the OS follows it by default, stat() will follow it", and (given some of your later comments), "when ERROR_CANT_ACCESS_FILE occurs on a reparse point (is that the only scenario?) behave like lstat()". (And I carefully phrased that to not imply that Python is going to partially follow a link chain for you if the eventual end result is not valid. e.g. stat() on a symlink to an appexeclink will return the symlink, because ERROR_CANT_ACCESS_FILE was the result. Then the suggestion will be "if stat() returns a link, use os.path.realpath() if you want to resolve it as far as possible".) > The questions for me are whether os.readlink() should also read > junctions and exactly what follow_symlinks means in Windows. We have a > complicated story to tell if follow_symlinks=False (lstat) opens any > reparse point or opens just name-surrogate reparse points, and islink() > is made consistent with this, but then readlink() doesn't work. I don't think it's that complicated: * os.lstat() will not traverse any links or reparse points * os.stat() will traverse any links and reparse points supported by the OS, or else return the same as os.lstat() * os.readlink() can read the target of a symlink or (on Windows) junction point > If junctions are handled as symlinks, then islink(), readlink(), > symlink() would be used to copy a junction 'link' while copying a tree > (e.g. shutil.copytree with symlinks=True). This would transform > junctions into directory symlinks. In this case, we potentially have a > problem that relative symlinks in the tree no longer target the same > files when accessed via a directory symlink instead of a junction. No > one thinks about this problem on the POSIX side because it would be > weird to copy a mountpoint as a symlink. In POSIX, a mountpoint is > always seen as just a directory and always traversed. This isn't difficult to handle specifically if we want to, though, since the stat result now includes the reparse tag. And you're right, we probably have to handle it. >> I'm still not convinced that this is what we want to do. I don't >> have a true Linux machine handy to try it out (Python 3.6 and 3.7 on >> WSL behave exactly like the semantics I'm proposing, but that may >> just be because it's the Windows kernel below it). > ... This is a decision in WSL's drvfs file-system driver, and I have to > assume it's intentional. I assumed it was intentional as well, though it'll almost certainly be based on pragmatically getting things to work (e.g. the '/mnt/c/Document and Settings' junction... though now I try it that those don't actually work...) >> ismount() is currently not true for junctions. And I can't find any >> reference that says that POSIX symlinks can't point to directories, > > Our current implementation for junctions is based on GetVolumePathNameW, > which will be true for junctions that use the "Volume{...}" name to > mount the file-system root directory. That's a volume mount point. > > I don't know why someone decided that's the sum total of "mount point" > in Windows. DOS drives and UNC drives can refer to arbitrary file system > directories. They don't have to refer to file-system root directory. We > can have "W:" -> "\\??\\C:\\Windows", etc. > > Per the docs, a mount point for ismount() is a "point in a file system > where a different file system has been mounted". The mounted directory > doesn't have to be the root directory of the file system. I'd relax this > definition to include all "hard" name grafting links to other > directories, even within the same file system. What matter to me is the > semantics of how this differs from the soft name grafting of a symlink. I think the intent is that it's mounted the root of another file system. There was discussion of just using the reparse tag in issue9035, but it looks like from msg138197 that returning True for regular directory links was not the intent (despite the tests in that message being insufficient). > If follow_symlinks=False applies to name surrogates, then a junction > would be detectable via os.lstat(filename).st_reparse_tag, which is not > only much cheaper than GetVolumePathNameW, but also more generally > correct and consistent with DOS and UNC drive mount points. Ah, the future possibilities of getting that one field added in this PR :) Let's save other enhancements for another PR - especially when they won't be impacted by this one. > S_IFDIR is suppressed for directory symlinks in the stat result. But > os.path.isdir() is supposed to be based on os.stat, and thus follows > symlinks. To that end, our nt._isdir is broken because it assumes > GetFileAttributesW is sufficient. Since we're supposed to follow links, > it's not working right for link targets that don't exist. It should > return False in that case. That's easily fixed. > I assumed stat() would return the reparse point for all tags that fail > to reparse with ERROR_CANT_ACCESS_FILE since it's not an invalid reparse > point, just an unhandled one that has no other significance at the file > system level. To stat(), it can never be anything other than a reparse > point. Whatever relevance it has depends on some other context (e.g. a > CreateProcessW call). This is easy - just remove the "call again with traverse=TRUE" - and provided we don't set S_IFLNK in this case then we are being "correct", right? (Nobody has yet defined whether S_IFLNK is required for st_reparse_tag to be set.) > That doesn't mean, however, that I wouldn't like the ability to detect > "name surrogate" reparse points in general to implement safer behavior > for shutil.rmtree and anything else that walks a directory tree. nt.lstat().st_reparse_tag and the constants in the stat module are sufficient for this, right? > If islink() is true, then st_mode has S_IFLNK and not S_IFDIR. So we > have a mount point that's a symlink, which is not possible in POSIX, and > it's not a directory, which is unusual in POSIX to say the least. This entire discussion is because POSIX can't fully describe Windows filesystems :) The two goals need to be making the "most consistent" behaviour the default, while enabling special cases to be specialised. So I care less about the correct information being reported than it being acted upon in the correct way - if that means lying about junctions and mount points being links and not directories (since POSIX apparently doesn't support setting both flags?), then let's lie about it. lstat().st_reparse_tag will reveal whether it's a junction, and ismount() whether it's linking to a different device. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 13:05:22 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 16 Aug 2019 17:05:22 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565975122.79.0.338504281751.issue37834@roundup.psfhosted.org> Steve Dower added the comment: That was a long set of replies, so here's my summary proposed behaviour: (Where "links" are the generic term for the set that includes "reparse point", "symlink", "mount point", "junction", etc.) os.lstat(path): returns attributes for path without traversing any kind of links os.stat(path): traverses any links supported by the OS and returns attributes for the final file - on Windows, if the OS reports that a link is not followable (e.g. appexeclink), then the original link is reported. So if S_IFLNK is set in the result, the caller should, use os.path.realpath() to traverse as many links as possible to reach the unfollowable link os.exists(path): now returns True for links that exist but the OS reports are not followable - previously returned False (links that are followable but the target does not exist continue to return False) os.path.is_dir(path): now returns False for directory links where the target does not exist os.unlink(path): unchanged (still removes the junction, not the contents) os.scandir(path): DirEntry.is_symlink() and DirEntry.is_dir() will now both be True for junctions (this was always the case for symlinks to directories). DirEntry.stat(follow_symlinks=False).st_reparse_tag == stat.IO_REPARSE_TAG_MOUNT_POINT is how to specifically detect a junction. shutil.copytree(path): Unchanged. (requires a minor fix to continue to recursively copy through junctions (using above test), but not symlinks.) shutil.rmtree(path): Will now remove a junction rather than recursively deleting its contents (net improvement, IMHO) And as I said at the end of the long post, my main goals are: * the result of _using_ the returned information should be consistent across OS * there are ways of getting more specific information when needed The most impactful change would seem to be the one to DirEntry, in that users may now treat junction points more like symlinks than real directories depending on how they've set up their checks. But for the other benefits - particularly the more reliable exists() checks - I think this is worth it overall. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 13:16:20 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 16 Aug 2019 17:16:20 +0000 Subject: [issue24754] argparse add_argument with action="store_true", type=bool should not crash In-Reply-To: <1438250218.94.0.699008040775.issue24754@psf.upfronthosting.co.za> Message-ID: <1565975780.41.0.0459527829903.issue24754@roundup.psfhosted.org> Joannah Nanjekye added the comment: See issue25299 also. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 13:26:02 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 16 Aug 2019 17:26:02 +0000 Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4 given) In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za> Message-ID: <1565976362.43.0.231300962264.issue25299@roundup.psfhosted.org> Joannah Nanjekye added the comment: > this argument defaults to "None" Am leaning to the fact that this works as required. The documentation does not just say defaults to none. It says: With the 'store_const' and 'append_const' actions, the const keyword argument must be given. For other actions, it defaults to None. In the scenario, you have given, you are using 'store_const' so the const keyword argument must be given. This should be closed If you agree with what I have just stated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 13:52:04 2019 From: report at bugs.python.org (Michael Hearn) Date: Fri, 16 Aug 2019 17:52:04 +0000 Subject: [issue37877] MacOS crash appJar 3.7.3 Message-ID: <1565977924.82.0.581116277881.issue37877@roundup.psfhosted.org> Change by Michael Hearn : ---------- components: macOS nosy: Michael Hearn, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: MacOS crash appJar 3.7.3 versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 14:23:36 2019 From: report at bugs.python.org (Greg Price) Date: Fri, 16 Aug 2019 18:23:36 +0000 Subject: [issue37872] Move statics in Python/import.c to top of the file In-Reply-To: <1565961670.68.0.815730473417.issue37872@roundup.psfhosted.org> Message-ID: <1565979816.32.0.762703528033.issue37872@roundup.psfhosted.org> Change by Greg Price : ---------- nosy: +Greg Price _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 14:24:38 2019 From: report at bugs.python.org (Greg Price) Date: Fri, 16 Aug 2019 18:24:38 +0000 Subject: [issue37872] Move _Py_IDENTIFIER statics in Python/import.c to top of the file In-Reply-To: <1565961670.68.0.815730473417.issue37872@roundup.psfhosted.org> Message-ID: <1565979878.49.0.618958917176.issue37872@roundup.psfhosted.org> Change by Greg Price : ---------- title: Move statics in Python/import.c to top of the file -> Move _Py_IDENTIFIER statics in Python/import.c to top of the file _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 14:25:53 2019 From: report at bugs.python.org (Greg Price) Date: Fri, 16 Aug 2019 18:25:53 +0000 Subject: [issue37872] Move _Py_IDENTIFIER statics in Python/import.c to top of the file In-Reply-To: <1565961670.68.0.815730473417.issue37872@roundup.psfhosted.org> Message-ID: <1565979953.07.0.466661269711.issue37872@roundup.psfhosted.org> Change by Greg Price : ---------- components: +Interpreter Core _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 14:34:39 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 16 Aug 2019 18:34:39 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1565980479.49.0.796151556703.issue9949@roundup.psfhosted.org> Steve Dower added the comment: Another minor change worth calling out - I added a note to the docs that when a symlink cycle is detected, realpath() could return any member of the cycle, but does not guarantee which one. For our test cases it's generally stable enough, but if you change the starting point (e.g. from absolute to relative path) then it can change the result. It seemed easier all round just to not guarantee anything about which member of the cycle will be returned, rather than determining the exact rules, reproducing them across all platforms, and documenting them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 15:12:55 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 16 Aug 2019 19:12:55 +0000 Subject: [issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class In-Reply-To: <1565689003.91.0.0312877377737.issue37835@roundup.psfhosted.org> Message-ID: <1565982775.0.0.429691458401.issue37835@roundup.psfhosted.org> Change by Ivan Levkivskyi : ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 15:36:39 2019 From: report at bugs.python.org (Michael Hearn) Date: Fri, 16 Aug 2019 19:36:39 +0000 Subject: [issue37877] MacOS crash appJar 3.7.3 Message-ID: <1565984199.8.0.985366763884.issue37877@roundup.psfhosted.org> New submission from Michael Hearn : macOS 10.14.6 -anaconda install Python 3.7.3 pip install appJar (0.94.0) On start of app with app.go() a crash will occur causing mac to logout. Python 3.7.2 does not show this behavior Will document on medium. https://raw.githubusercontent.com/borosilicate/RCSB-Protein-Data-Bank-CSV-Maker/master/pygui.py ---------- nosy: -ned.deily, ronaldoussoren type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 15:53:55 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 16 Aug 2019 19:53:55 +0000 Subject: [issue37878] sub-ineterpreters : Document PyThreadState_DeleteCurrent() ? Message-ID: <1565985235.6.0.212314052144.issue37878@roundup.psfhosted.org> New submission from Joannah Nanjekye : I just noticed that PyThreadState_DeleteCurrent()in Python/pystate.c is not documented. Relevant documentation should go in Doc/c-api/init.rst If no one objects to this. ---------- assignee: docs at python components: Documentation keywords: easy messages: 349881 nosy: docs at python, eric.snow, nanjekyejoannah, ncoghlan, vstinner priority: normal severity: normal stage: needs patch status: open title: sub-ineterpreters : Document PyThreadState_DeleteCurrent() ? versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 15:55:26 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 16 Aug 2019 19:55:26 +0000 Subject: [issue37877] MacOS crash appJar 3.7.3 In-Reply-To: <1565984199.8.0.985366763884.issue37877@roundup.psfhosted.org> Message-ID: <1565985326.07.0.14041331144.issue37877@roundup.psfhosted.org> Ronald Oussoren added the comment: Does this application use Tkinter? If so, this is a duplicate of #37833, and a bug in macOS triggered by (amongst others) anaconda but (AFAIK) not by the Python.org installer. The "logout" is a crash in the WindowServer proces, which is something that should never happen. I've filed an issue with Apple about that, but have no idea if or when they will look at that. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 15:55:46 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 16 Aug 2019 19:55:46 +0000 Subject: [issue37878] Sub-ineterpreters : Document PyThreadState_DeleteCurrent() ? In-Reply-To: <1565985235.6.0.212314052144.issue37878@roundup.psfhosted.org> Message-ID: <1565985346.91.0.99848816863.issue37878@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- title: sub-ineterpreters : Document PyThreadState_DeleteCurrent() ? -> Sub-ineterpreters : Document PyThreadState_DeleteCurrent() ? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 15:56:37 2019 From: report at bugs.python.org (Mairi Dulaney) Date: Fri, 16 Aug 2019 19:56:37 +0000 Subject: [issue37593] ast.arguments has confusing args/posonlyargs ordering In-Reply-To: <1563130537.16.0.669672983776.issue37593@roundup.psfhosted.org> Message-ID: <1565985397.5.0.561628550518.issue37593@roundup.psfhosted.org> Mairi Dulaney added the comment: The patch that was merged to fix this may have caused a regresion in xonsh. Am working on a reproducer. ---------- nosy: +mdulaney _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 15:57:21 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 16 Aug 2019 19:57:21 +0000 Subject: [issue37878] Sub-Interpreters : Document PyThreadState_DeleteCurrent() In-Reply-To: <1565985235.6.0.212314052144.issue37878@roundup.psfhosted.org> Message-ID: <1565985441.16.0.296439999368.issue37878@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- title: Sub-ineterpreters : Document PyThreadState_DeleteCurrent() ? -> Sub-Interpreters : Document PyThreadState_DeleteCurrent() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 16:00:06 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Fri, 16 Aug 2019 20:00:06 +0000 Subject: [issue37878] Sub-Interpreters : Document PyThreadState_DeleteCurrent() In-Reply-To: <1565985235.6.0.212314052144.issue37878@roundup.psfhosted.org> Message-ID: <1565985606.5.0.159400695246.issue37878@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- keywords: +patch pull_requests: +15034 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15315 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 16:00:13 2019 From: report at bugs.python.org (Tal Einat) Date: Fri, 16 Aug 2019 20:00:13 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1565985613.1.0.0147353945148.issue37824@roundup.psfhosted.org> Tal Einat added the comment: I see none of this on latest master (0567786d26348aa7eaf0ab1b5d038fdabe409d92) on Windows 10. Can you specify on what OS and Python branch/version this happens? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 16:26:19 2019 From: report at bugs.python.org (Hansraj Das) Date: Fri, 16 Aug 2019 20:26:19 +0000 Subject: [issue37732] Possible uninitialized variable in Objects/obmalloc.c In-Reply-To: <1564582636.59.0.312005293129.issue37732@roundup.psfhosted.org> Message-ID: <1565987179.94.0.841848323079.issue37732@roundup.psfhosted.org> Change by Hansraj Das : ---------- keywords: +patch pull_requests: +15035 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15309 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 16:42:50 2019 From: report at bugs.python.org (Michael Hearn) Date: Fri, 16 Aug 2019 20:42:50 +0000 Subject: [issue37877] MacOS crash appJar 3.7.3 In-Reply-To: <1565985326.07.0.14041331144.issue37877@roundup.psfhosted.org> Message-ID: Michael Hearn added the comment: Thanks for the fast response it uses appJar which is a very similar GUI package but not the same one. AppJar is based of it but I don?t believe it was built off it. On Fri, Aug 16, 2019 at 3:55 PM Ronald Oussoren wrote: > > Ronald Oussoren added the comment: > > Does this application use Tkinter? > > If so, this is a duplicate of #37833, and a bug in macOS triggered by > (amongst others) anaconda but (AFAIK) not by the Python.org installer. > > The "logout" is a crash in the WindowServer proces, which is something > that should never happen. I've filed an issue with Apple about that, but > have no idea if or when they will look at that. > > ---------- > nosy: +ronaldoussoren > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 16:56:17 2019 From: report at bugs.python.org (Michael Hearn) Date: Fri, 16 Aug 2019 20:56:17 +0000 Subject: [issue37877] MacOS crash appJar 3.7.3 In-Reply-To: <1565984199.8.0.985366763884.issue37877@roundup.psfhosted.org> Message-ID: <1565988977.65.0.429868524874.issue37877@roundup.psfhosted.org> Change by Michael Hearn : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 17:10:01 2019 From: report at bugs.python.org (Christian Heimes) Date: Fri, 16 Aug 2019 21:10:01 +0000 Subject: [issue17305] IDNA2008 encoding is missing In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za> Message-ID: <1565989801.22.0.568398791313.issue17305@roundup.psfhosted.org> Christian Heimes added the comment: There is no consensus yet. Besides https://pypi.org/project/idna/ we could also consider to wrap libidn2 and ship it. Both PyPI idna and libidn2 have potential licensing issues. I don't like the idea to reinvent the wheel and implement our own idna2008 codec. It's not a trivial task. Once Python has a working idna2008 encoder, we need to address integration into socket, ssl, http, and asyncio module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 17:10:23 2019 From: report at bugs.python.org (Michael Hearn) Date: Fri, 16 Aug 2019 21:10:23 +0000 Subject: [issue37877] MacOS crash appJar 3.7.3 In-Reply-To: <1565984199.8.0.985366763884.issue37877@roundup.psfhosted.org> Message-ID: <1565989823.35.0.154331109478.issue37877@roundup.psfhosted.org> Michael Hearn added the comment: Hopefully apple will fix this. https://medium.com/@michaeljosephhearn/macos-mojave-crash-6fd1e69d3d34 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 17:58:04 2019 From: report at bugs.python.org (Abhilash Raj) Date: Fri, 16 Aug 2019 21:58:04 +0000 Subject: [issue37826] Document PEP 3134 in tutorials/errors.rst In-Reply-To: <1565548566.46.0.213467869715.issue37826@roundup.psfhosted.org> Message-ID: <1565992684.43.0.637044311967.issue37826@roundup.psfhosted.org> Change by Abhilash Raj : ---------- stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 18:14:04 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 16 Aug 2019 22:14:04 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565993644.53.0.0320037706152.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > Where "links" are the generic term for the set that includes > "reparse point", "symlink", "mount point", "junction", etc.) Why group all reparse points under the banner of 'link'? If we have a typical HSM reparse point (the vast majority of allocated tags), then all operations, such as delete and rename, act on the file itself, not simply the reparse point. We should be able to delete or rename a link without affecting the target. In this case, there's also no chance that the reparse point is a surrogate for another path on the system, so code that walks paths doesn't have to worry about loops with regard to these reparse points. The only practical use case I can think of for detecting/opening this type of reparse point is backup software that should avoid triggering an HSM recall. For example: https://www.ibm.com/support/knowledgecenter/en/SSEQVQ_8.1.0/client/r_opt_hsmreparsetag.html As I've previously suggested (and this is the last time because I'm becoming a broken record), lstat() should at least be restricted to opening only name-surrogate reparse points that are supposed to be like links in that they target another path in the system. Plus it also has to open unhandled reparse points. Personally, I'm only comfortable with opening it up to name surrogates if islink() and readlink() are still limited to just Unix-like symlinks that we can create via symlink(). Nothing changes there. It's just a restriction of how lstat() currently works. The addition of the reparse tag in the stat result enables special handling of non-symlink surrogates. > shutil.copytree(path): Unchanged. (requires a minor fix to > continue to recursively copy through junctions (using above test), > but not symlinks.) Everyone else who relies on islink(), readlink(), and symlink() to copy symlinks isn't special casing their code to look for junctions or anything else we lump under the banner of islink(). They could code defensively if readlink() fails for a 'link' that we can't read. But that leaves the problem of readlink() succeeding for a junction. That can causes problems if the target is passed to os.symlink(), which changes the link from a hard name grafting to a soft name grafting. Why would we need to read the target of a junction? It's not needed for realpath() in Windows. We should only have to resolve symlinks. For example: C:/Mount/junction/spam/eggs junction -> Z:/bar/baz We don't have to resolve this as "Z:/bar/baz/spam/eggs", and doing so may even be wrong for someone using it to manually resolve a relative symlink. "C:/Mount/junction/spam/eggs" is a solid path. In Unix it would not be resolved by realpath(). A solid path is needed to figure out how to create a relative symlink, or how to manually resolve one for a given path. For example, if "foo_link" in "C:/Mount/junction/spam/eggs" targets "../../../foo", this refers to "C:/Mount/foo". On the other hand, if the junction mount point were replaced by a soft symlink, then "C:/Mount/symlink/spam/eggs" is not a solid path. "foo_link" is instead evaluated over the target path: "Z:/bar/baz/spam/eggs/foo_link", so the link resolves to "Z:/bar/foo". IMO, S_IFLNK need not be set for anything other than Unix-like symbolic links. We would just need to document that on Windows, lstat opens any link-like reparse point that indicates it targets another path on the system, plus any reparse point that's not handled, but that islink() is only true for actual Unix symlinks that can be created via os.symlink() and read via os.readlink(). This preserves how islink() and readlink() currently work, while still leaving the door open to fix misbehavior in particular cases. Code, including our own code, that needs to look for the broader Windows category of "name surrogate" can examine the reparse tag. For convenience we can provide issurrogate() that checks lstat(filename).st_reparse_tag & 0x2000_0000. This can be true for directories. Also, a surrogate doesn't have to behave like a Unix "soft" symlink, i.e. it applies to "hard" mount points. In Unix, issurrogate() could just be an alias for islink() since Unix provides only one type of name surrogate. Currently the name surrogate category includes the following tags: Microsoft name surrogate (bits 31 and 29) IO_REPARSE_TAG_MOUNT_POINT 0xA0000003 IO_REPARSE_TAG_SYMLINK 0xA000000C IO_REPARSE_TAG_IIS_CACHE 0xA0000010 IO_REPARSE_TAG_GLOBAL_REPARSE 0xA0000019 IO_REPARSE_TAG_LX_SYMLINK 0xA000001D IO_REPARSE_TAG_WCI_TOMBSTONE 0xA000001F IO_REPARSE_TAG_PROJFS_TOMBSTONE 0xA0000022 Non-Microsoft name surrogate (bit 29) IO_REPARSE_TAG_SOLUTIONSOFT 0x2000000D IO_REPARSE_TAG_OSR_SAMPLE 0x20000017 IO_REPARSE_TAG_QI_TECH_HSM 0x2000002F IO_REPARSE_TAG_MAXISCALE_HSM 0x20000035 IO_REPARSE_TAG_ALERTBOOT 0x2000004C IO_REPARSE_TAG_NVIDIA_UNIONFS 0x20000054 IO_REPARSE_TAG_OSR_SAMPLE is used by OSR sample code in their Windows driver curriculum, so that one is unlikely to be seen in practice. I don't know anything about the other non-Microsoft tags. NVidia's UnionFS looks interesting. Using reparse points to merge file systems is probably not the most efficient way to handle that problem, but I'm sure the devil is in the details there. > os.unlink(path): unchanged (still removes the junction, not the > contents) Whatever we're calling a link should be capable of being deleted via os.unlink. If we apply S_IFLNK, then it won't have S_IFDIR (at least how POSIX code expects it), and unlink should work on it. The current state of affairs in which unlink/remove works on a junction, which is reported by stat() as a directory, is inconsistent. It's not specified to remove directories, so nothing that it can remove should be a directory. > shutil.rmtree(path): Will now remove a junction rather than > recursively deleting its contents (net improvement, IMHO) I'd like for it to remove all name-surrogate directories like CMD's `rmdir /s` does. In contrast, Unix shutil.rmtree traverses into a mount point, deletes everything, and then fails because the directory is mounted and can't be removed. That's hideous, IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 18:22:23 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 16 Aug 2019 22:22:23 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565994143.67.0.875706549306.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > the '/mnt/c/Document and Settings' junction... though now I try > it that those don't actually work...) The security on compatibility junctions denies everyone read-data (list) access, but in Windows they can still be traversed (e.g. "C:/Documents and Settings/Public") because execute (traverse) access isn't denied, and even if it were denied, standard Windows users have SeChangeNotifyPrivilege to bypass traverse checking. I created a test junction named "eggs" that targets a directory named "spam" that has "spam/foo" subdirectory. I set the junction's security to match that of "Documents and Settings". In WSL, trying to traverse it to stat the "foo" subdirectory failed with EACCES, just as with "Documents and Settings/Public". After removing the entry that denies read-data access, it worked fine. There's no problem traversing "spam" directly if I set the same security on it that denies everyone read-data access; it only prevents listing the directory. It seems that in order to evaluate an NT junction, drvfs tries to open it with read-data access. I don't see why it would have to do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 19:59:54 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 16 Aug 2019 23:59:54 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1565999994.64.0.603744678.issue37834@roundup.psfhosted.org> Steve Dower added the comment: > Why group all reparse points under the banner of 'link'? Because for the purposes of the list of changes beneath it, there wasn't any difference (e.g. "traverses any links supported by the OS" is more meaningful to most people, even though both of us would understand it to mean "traverses any traversable reparse points supported by the OS"). I'm not redefining them all to be the same thing, just establishing the terminology for what immediately followed. > As I've previously suggested (and this is the last time because I'm > becoming a broken record), lstat() should at least be restricted to > opening only name-surrogate reparse points that are supposed to be like > links in that they target another path in the system. Plus it also has > to open unhandled reparse points. Apologies for causing the repetition. Let me summarise what I believe you're suggesting as an alternate flow (bearing in mind that only os.stat() and os.lstat() are affected here): os.lstat: * open without following reparse points * check the reparse tag - if it's a genuine symlink, return attributes of the link itself and marked ST_IFLNK - if it's a directory junction, call os.stat instead and return that (???) - if it's any name-surrogate reparse point, return attributes of the link itself but not marked ST_IFLNK - if it's any other reparse point, call os.stat instead and return that * otherwise regular handling (using hFile or FindFirstFile, etc.) os.stat: * open following reparse points * if the open fails with ERROR_CANT_ACCESS_FILE, try opening without following reparse points: - if it's a genuine symlink, ??? - if it's a directory junction, ??? - if it's any name-surrogate reparse point, ??? - if it's any other reparse point, return attributes of the link itself * otherwise regular handling If you can fill in the gaps, that will help me understand exactly what you're proposing. >> shutil.copytree(path): Unchanged. (requires a minor fix to >> continue to recursively copy through junctions (using above test), >> but not symlinks.) > > Everyone else who relies on islink(), readlink(), and symlink() to copy > symlinks isn't special casing their code to look for junctions or > anything else we lump under the banner of islink(). They could code > defensively if readlink() fails for a 'link' that we can't read. But > that leaves the problem of readlink() succeeding for a junction. That > can causes problems if the target is passed to os.symlink(), which > changes the link from a hard name grafting to a soft name grafting. Right, but is that because they deliberately want the junction to be treated like a file? Or because they want it to be treated like the directory is really right there? os.rmdir() already does special things to behave like a junction rather than the real directory, and the islink/readlink/symlink process is going to be problematic on Windows since most users can't create symlinks. That code simply isn't going to be portable. But code that is using stat() and expecting to get the real directory ought to work, just as code using lstat() and expecting to get the link if it's been linked somehow ought to work. > Why would we need to read the target of a junction? It's not needed for > realpath() in Windows. We should only have to resolve symlinks. For > example: > > ... > > IMO, S_IFLNK need not be set for anything other than Unix-like symbolic > links. We would just need to document that on Windows, lstat opens any > link-like reparse point that indicates it targets another path on the > system, plus any reparse point that's not handled, but that islink() is > only true for actual Unix symlinks that can be created via os.symlink() > and read via os.readlink(). I think I understand your reasoning here now, sorry for it taking so long. > This preserves how islink() and readlink() currently work, while still > leaving the door open to fix misbehavior in particular cases. Code, > including our own code, that needs to look for the broader Windows > category of "name surrogate" can examine the reparse tag. For > convenience we can provide issurrogate() that checks > lstat(filename).st_reparse_tag & 0x2000_0000. I'm not adding new API, even for internal use. This is edge case enough that os.lstat() is fine for it. >> os.unlink(path): unchanged (still removes the junction, not the >> contents) > > Whatever we're calling a link should be capable of being deleted via > os.unlink. If we apply S_IFLNK, then it won't have S_IFDIR (at least how > POSIX code expects it), and unlink should work on it. The current state > of affairs in which unlink/remove works on a junction, which is reported > by stat() as a directory, is inconsistent. It's not specified to remove > directories, so nothing that it can remove should be a directory. I'm proposing to fix the inconsistency by fixing the flags. Your proposal is to fix the inconsistency by generating a new error in unlink()? (Just clarifying.) >> shutil.rmtree(path): Will now remove a junction rather than >> recursively deleting its contents (net improvement, IMHO) > > I'd like for it to remove all name-surrogate directories like CMD's > `rmdir /s` does. In contrast, Unix shutil.rmtree traverses into a mount > point, deletes everything, and then fails because the directory is > mounted and can't be removed. That's hideous, IMO. Currently Windows shutil.rmtree traverses into junctions and deletes everything, though it then succeeds to delete the junction. With my change, rmtree() directly on a junction now raises (could be fixed?) but rmtree on a directory containing a junction will remove the junction without touching the target directory. So I think we're both happy about this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 20:01:00 2019 From: report at bugs.python.org (Kyle Stanley) Date: Sat, 17 Aug 2019 00:01:00 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1566000060.32.0.0442763837022.issue34155@roundup.psfhosted.org> Kyle Stanley added the comment: > This is already backported to 3.6. I am not sure about what gets backported to 3.5 right now, I don't even see a 'Backport to 3.5' label on Github (which made me think we are discouraged to backport to 3.5). I can work on a manual backport if needed? As far as I'm aware, backports to 3.5 have to be manually approved by those with repository management permissions, such the the organization owners (https://devguide.python.org/devcycle/#current-owners) and admins (https://devguide.python.org/devcycle/#current-administrators) ---------- nosy: +aeros167 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 22:14:00 2019 From: report at bugs.python.org (Abhilash Raj) Date: Sat, 17 Aug 2019 02:14:00 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1566008040.29.0.650275685174.issue34155@roundup.psfhosted.org> Change by Abhilash Raj : ---------- pull_requests: +15036 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/15317 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 22:15:34 2019 From: report at bugs.python.org (Abhilash Raj) Date: Sat, 17 Aug 2019 02:15:34 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1566008134.68.0.768699676846.issue34155@roundup.psfhosted.org> Abhilash Raj added the comment: Created a backport PR for 3.5. ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 22:47:34 2019 From: report at bugs.python.org (Alexander Pyhalov) Date: Sat, 17 Aug 2019 02:47:34 +0000 Subject: [issue37790] subprocess.Popen() is extremely slow In-Reply-To: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org> Message-ID: <1566010054.72.0.00809084861025.issue37790@roundup.psfhosted.org> Alexander Pyhalov added the comment: I couldn't reproduce entire test, as wsdiff script is rather large, but here's the simplified version. If Popen is used more often, difference is much more significant. # Using workaround $ python3.5 ~/tmp/1.py 1 10.780487537384033 # Without workaround $ python3.5 ~/tmp/1.py 13.347045660018921 # Using python2.7 $ python2.7 ~/tmp/1.py 9.83385586739 ---------- Added file: https://bugs.python.org/file48549/1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 22:53:20 2019 From: report at bugs.python.org (Alexander Pyhalov) Date: Sat, 17 Aug 2019 02:53:20 +0000 Subject: [issue37790] subprocess.Popen() is extremely slow In-Reply-To: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org> Message-ID: <1566010400.92.0.772558262053.issue37790@roundup.psfhosted.org> Alexander Pyhalov added the comment: Even if I use import subprocess process = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True, universal_newlines=True) return process.stdout.read() difference in times are the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 23:01:56 2019 From: report at bugs.python.org (Abhilash Raj) Date: Sat, 17 Aug 2019 03:01:56 +0000 Subject: [issue29412] IndexError thrown on email.message.Message.get In-Reply-To: <1485957201.62.0.708721670813.issue29412@psf.upfronthosting.co.za> Message-ID: <1566010916.4.0.215098992843.issue29412@roundup.psfhosted.org> Change by Abhilash Raj : ---------- stage: patch review -> resolved status: open -> closed versions: +Python 3.8, Python 3.9 -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 23:03:39 2019 From: report at bugs.python.org (Abhilash Raj) Date: Sat, 17 Aug 2019 03:03:39 +0000 Subject: [issue21315] email._header_value_parser does not recognise in-line encoding changes In-Reply-To: <1398009498.59.0.139606640186.issue21315@psf.upfronthosting.co.za> Message-ID: <1566011019.24.0.40214402086.issue21315@roundup.psfhosted.org> Change by Abhilash Raj : ---------- stage: patch review -> resolved status: open -> closed versions: +Python 3.7, Python 3.8 -Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 16 23:06:38 2019 From: report at bugs.python.org (Abhilash Raj) Date: Sat, 17 Aug 2019 03:06:38 +0000 Subject: [issue35805] email package folds msg-id identifiers using RFC2047 encoded words where it must not In-Reply-To: <1548161762.46.0.975813554813.issue35805@roundup.psfhosted.org> Message-ID: <1566011198.78.0.327946484464.issue35805@roundup.psfhosted.org> Abhilash Raj added the comment: I am slightly confused if this should be backported to bugfix branches since this is technically a new feature, the ability to parse Message-ID field. I would love to see what David and Barry think about this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 01:40:06 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 17 Aug 2019 05:40:06 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1566020406.38.0.861433218622.issue37824@roundup.psfhosted.org> Terry J. Reedy added the comment: My first post described master at the time, when SyntaxWarnings were converted to SyntexErrors and shell input warnings, in particular, Deprecation warnings were sent to the console or nowhere. My third post describes the situation with the PR, where SyntaxWarnings are left as warnings and shell input warnings go to shell. An improvement, but still buggy. I just reconfirmed after updating, compiling Python, and checking out my 'warn' branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 02:28:19 2019 From: report at bugs.python.org (Hansraj Das) Date: Sat, 17 Aug 2019 06:28:19 +0000 Subject: [issue37732] Possible uninitialized variable in Objects/obmalloc.c In-Reply-To: <1564582636.59.0.312005293129.issue37732@roundup.psfhosted.org> Message-ID: <1566023299.05.0.728966095109.issue37732@roundup.psfhosted.org> Change by Hansraj Das : ---------- nosy: +hansrajdas _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 03:09:09 2019 From: report at bugs.python.org (Roundup Robot) Date: Sat, 17 Aug 2019 07:09:09 +0000 Subject: [issue36947] [Good first issue] Fix 3.3.3.1 Metaclasses Documentation In-Reply-To: <1558103271.07.0.643884881507.issue36947@roundup.psfhosted.org> Message-ID: <1566025749.68.0.876701852528.issue36947@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +15037 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15319 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 05:18:39 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 17 Aug 2019 09:18:39 +0000 Subject: [issue37790] subprocess.Popen() is extremely slow In-Reply-To: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org> Message-ID: <1566033519.95.0.375032747451.issue37790@roundup.psfhosted.org> Antoine Pitrou added the comment: I don't seen any significant difference here (Ubuntu 18.04): $ time python2 sp.py 10.3433089256 real 0m10,362s user 0m6,565s sys 0m4,372s $ time python3 sp.py 11.746907234191895 real 0m11,781s user 0m7,356s sys 0m5,239s ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 09:00:38 2019 From: report at bugs.python.org (Bennet Fauber) Date: Sat, 17 Aug 2019 13:00:38 +0000 Subject: [issue37565] test_faulthandler: test_register_chain() crash with SIGSEGV (signal 11) on Skylake chipset In-Reply-To: <1562857971.79.0.0137287316017.issue37565@roundup.psfhosted.org> Message-ID: <1566046838.55.0.860714077019.issue37565@roundup.psfhosted.org> Bennet Fauber added the comment: It would appear that jshelly was correct and this is resolved by fixing the problem isolated in issue 21131, which was closed and a patch was committed. https://github.com/python/cpython/pull/15276 ---------- nosy: +justbennet _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 09:42:50 2019 From: report at bugs.python.org (A. Skrobov) Date: Sat, 17 Aug 2019 13:42:50 +0000 Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4 given) In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za> Message-ID: <1566049370.48.0.476950697389.issue25299@roundup.psfhosted.org> A. Skrobov added the comment: Joannah, I see that under #25314, the docs were updated to match the implementation: https://github.com/python/cpython/commit/b4912b8ed367e540ee060fe912f841cc764fd293 On the other hand, the discussion here (from 2015) and on #25314 (from 2016) includes suggestions for improvements in the implementation as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 10:02:17 2019 From: report at bugs.python.org (Erik Janssens) Date: Sat, 17 Aug 2019 14:02:17 +0000 Subject: [issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...) In-Reply-To: <1565351601.24.0.515340331062.issue37801@roundup.psfhosted.org> Message-ID: <1566050537.27.0.864182439193.issue37801@roundup.psfhosted.org> Erik Janssens added the comment: fyi 1 : this issue pops up in multiple places, cfr : * bpo-35890 * bpo-20596 the selection of the wcstok function is based on MS_WINDOWS being defined, rather than eg. an autoconf check on which function is available. fyi 2 : I've been able to cross compile 3.8 with mingw64 (gcc 7.3), but with a custom meson script instead of autoconf ---------- nosy: +erikjanss _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 12:13:28 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 17 Aug 2019 16:13:28 +0000 Subject: [issue37830] continue and break in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1566058408.23.0.184891515655.issue37830@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +15039 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15320 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 12:35:48 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 17 Aug 2019 16:35:48 +0000 Subject: [issue37830] continue and break in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1566059748.62.0.836449839569.issue37830@roundup.psfhosted.org> Serhiy Storchaka added the comment: PR 15320 fixes a regression by changing the compiler. None is now always pushed on the stack before entering a try...finally block. The "return" statement with a non-constant value replaces it, so the stack is balanced. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 12:47:51 2019 From: report at bugs.python.org (Davin Potts) Date: Sat, 17 Aug 2019 16:47:51 +0000 Subject: [issue37754] alter size of segment using multiprocessing.shared_memory In-Reply-To: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> Message-ID: <1566060471.14.0.29140683511.issue37754@roundup.psfhosted.org> Davin Potts added the comment: Attempts to alter the size of a shared memory segment are met with a variety of different, nuanced behaviors on systems we want to support. I agree that it would be valuable to be able to effectively realloc a shared memory segment, which thankfully the user can do with the current implementation although they become responsible for adjusting for platform-specific behaviors. The design of the API in multiprocessing.shared_memory strives to be as feature-rich as possible while providing consistent behavior across platforms that can be reasonably supported; it also leaves the door open (so to speak) for users to exploit additional platform-specific capabilities of shared memory segments. Knowing beforehand whether to create a segment or attach to an existing one is an important feature for a variety of use cases. I believe this is discussed at some length in issue35813. If what is discussed there does not help (it did get kind of long sometimes), please say so and we can talk through it more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 14:29:36 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Sat, 17 Aug 2019 18:29:36 +0000 Subject: [issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc In-Reply-To: <1563731175.2.0.136240000148.issue37645@roundup.psfhosted.org> Message-ID: <1566066576.02.0.826850060838.issue37645@roundup.psfhosted.org> Jeroen Demeyer added the comment: > I'm wary of making error messages depend on the str representation of a function; that would prevent us from changing it later. Why wouldn't we be able to change anything? Typically, the exact string of an error message is NOT part of the API (the exception *type* is, but we're not talking about that). > I'm wary of "%S" used in error messages. Those are for the programmer, not the user I'm not following here. Given that Python is a programming language, the user *is* the programmer. Anyway, you don't have to be convinced. I'm trying to solve a problem here and I have two approaches (PR 14890 and PR 15295). I'm more inclined towards PR 15295, but if you like the idea of PR 14890 better, we can go with that instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 14:45:22 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Sat, 17 Aug 2019 18:45:22 +0000 Subject: [issue37645] Replace PyEval_GetFuncName/PyEval_GetFuncDesc In-Reply-To: <1563731175.2.0.136240000148.issue37645@roundup.psfhosted.org> Message-ID: <1566067522.1.0.75443885441.issue37645@roundup.psfhosted.org> Jeroen Demeyer added the comment: > I'm wary of "%S" used in error messages. Maybe you're misunderstanding something. The goal is not really to change error messages, only the way how they are produced. For example, we currently have >>> def f(): pass >>> f(**1) Traceback (most recent call last): File "", line 1, in TypeError: f() argument after ** must be a mapping, not int This is about how the "f()" in the error message is produced. Currently, this uses PyEval_GetFuncName() and PyEval_GetFuncDesc(). For the reasons explained in this issue, I want to replace that. I see two ways of doing this: 1. (PR 14890) Write a new function _PyObject_FunctionStr(func) which returns func.__qualname__ + "()" with a suitable fallback if there is no __qualname__ attribute. At some point, we could also introduce a %F format character for this. 2. (PR 15295) Use str(func) in the error message and change various __str__ methods (really tp_str functions) to give a more readable output. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 15:28:25 2019 From: report at bugs.python.org (Hansraj Das) Date: Sat, 17 Aug 2019 19:28:25 +0000 Subject: [issue37869] Compilation warning on GCC version 7.4.0-1ubuntu1~18.04.1 In-Reply-To: <1565901041.74.0.0939495038375.issue37869@roundup.psfhosted.org> Message-ID: <1566070105.8.0.484554344074.issue37869@roundup.psfhosted.org> Change by Hansraj Das : ---------- resolution: -> duplicate _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 16:46:32 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Aug 2019 20:46:32 +0000 Subject: [issue37841] Python store app launcher has dependency on msvcp140.dll In-Reply-To: <1565711367.34.0.212877315326.issue37841@roundup.psfhosted.org> Message-ID: <1566074792.8.0.387985235701.issue37841@roundup.psfhosted.org> Change by Steve Dower : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 16:47:31 2019 From: report at bugs.python.org (Eddie Elizondo) Date: Sat, 17 Aug 2019 20:47:31 +0000 Subject: [issue37879] Segfaults in C heap type subclasses Message-ID: <1566074851.0.0.451710928537.issue37879@roundup.psfhosted.org> New submission from Eddie Elizondo : `subtype_dealloc` is not correctly handling the reference count of c heap type subclasses. It has some builtin assumptions which can result in the type getting its reference count decreased more that it needs to be, leading to its destruction when it should still be alive. Also, this bug is a blocker for the full adoption of PEP384. The full details of the bug along with a fix and tests are described in the Github PR. ---------- messages: 349905 nosy: eelizondo priority: normal severity: normal status: open title: Segfaults in C heap type subclasses _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 16:48:44 2019 From: report at bugs.python.org (Eddie Elizondo) Date: Sat, 17 Aug 2019 20:48:44 +0000 Subject: [issue37879] Segfaults in C heap type subclasses In-Reply-To: <1566074851.0.0.451710928537.issue37879@roundup.psfhosted.org> Message-ID: <1566074924.54.0.892972901038.issue37879@roundup.psfhosted.org> Change by Eddie Elizondo : ---------- keywords: +patch pull_requests: +15040 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15323 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 16:50:42 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Aug 2019 20:50:42 +0000 Subject: [issue36266] Which module could not be found? In-Reply-To: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org> Message-ID: <1566075042.85.0.0110369110327.issue36266@roundup.psfhosted.org> Steve Dower added the comment: New changeset 24fe46081be3d1c01b3d21cb39bc3492ab4485a3 by Steve Dower (shireenrao) in branch 'master': bpo-36266: Add module name in ImportError when DLL not found on Windows (GH-15180) https://github.com/python/cpython/commit/24fe46081be3d1c01b3d21cb39bc3492ab4485a3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 16:50:53 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 17 Aug 2019 20:50:53 +0000 Subject: [issue36266] Which module could not be found? In-Reply-To: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org> Message-ID: <1566075053.34.0.378777896841.issue36266@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15041 pull_request: https://github.com/python/cpython/pull/15324 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 16:51:12 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Aug 2019 20:51:12 +0000 Subject: [issue37734] Registry keys for Windows Store package have wrong executable In-Reply-To: <1564590002.03.0.889517252351.issue37734@roundup.psfhosted.org> Message-ID: <1566075072.89.0.990646330015.issue37734@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 16:53:46 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Aug 2019 20:53:46 +0000 Subject: [issue36266] Which module could not be found? In-Reply-To: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org> Message-ID: <1566075226.32.0.196194593537.issue36266@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 Aug 17 17:11:31 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 17 Aug 2019 21:11:31 +0000 Subject: [issue36266] Which module could not be found? In-Reply-To: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org> Message-ID: <1566076291.24.0.335499690053.issue36266@roundup.psfhosted.org> miss-islington added the comment: New changeset 786a4e1cef3eda8f434613d3801a5c7565fb5cd8 by Miss Islington (bot) in branch '3.8': bpo-36266: Add module name in ImportError when DLL not found on Windows (GH-15180) https://github.com/python/cpython/commit/786a4e1cef3eda8f434613d3801a5c7565fb5cd8 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 17:11:42 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Aug 2019 21:11:42 +0000 Subject: [issue36670] test suite broken due to cpu usage feature on win 10/ german In-Reply-To: <1555689157.38.0.435665423105.issue36670@roundup.psfhosted.org> Message-ID: <1566076302.71.0.515491318642.issue36670@roundup.psfhosted.org> Change by Steve Dower : ---------- keywords: +easy, newcomer friendly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 17:12:05 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Aug 2019 21:12:05 +0000 Subject: [issue37641] Embeddable distribution pyc filenames show build machine location In-Reply-To: <1563707241.42.0.696780467352.issue37641@roundup.psfhosted.org> Message-ID: <1566076325.55.0.947367112925.issue37641@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 17:12:40 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Aug 2019 21:12:40 +0000 Subject: [issue32910] venv: Deactivate.ps1 is not created when Activate.ps1 was used In-Reply-To: <1519299488.62.0.467229070634.issue32910@psf.upfronthosting.co.za> Message-ID: <1566076360.37.0.0729149858517.issue32910@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 Aug 17 17:13:36 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Aug 2019 21:13:36 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566076416.71.0.811088651303.issue37664@roundup.psfhosted.org> Steve Dower added the comment: Is pip 19.2.2 worth taking? Or are we expecting another patch this week? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 17:17:44 2019 From: report at bugs.python.org (Steve Dower) Date: Sat, 17 Aug 2019 21:17:44 +0000 Subject: [issue37552] [Windows] strptime/strftime return invalid results with UCRT version 17763.615 In-Reply-To: <1562790207.54.0.930380586709.issue37552@roundup.psfhosted.org> Message-ID: <1566076664.28.0.142058506969.issue37552@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 Aug 17 20:40:44 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 18 Aug 2019 00:40:44 +0000 Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4 given) In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za> Message-ID: <1566088844.72.0.503062615292.issue25299@roundup.psfhosted.org> Joannah Nanjekye added the comment: Since both the docs and implementation now match, I suggest we close this and open a new issue suggesting to change the implementation back to make const=None when action='store_const'. ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 20:41:15 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 18 Aug 2019 00:41:15 +0000 Subject: [issue37880] For argparse add_argument with action='store_const', const should default to None. Message-ID: <1566088875.45.0.199116489639.issue37880@roundup.psfhosted.org> New submission from Joannah Nanjekye : Currently, when `parser.add_argument()` is given argument with `action='store_const'` and no `const` argument , it throws an exception : >>> from argparse import ArgumentParser >>> parser = ArgumentParser() >>> parser.add_argument("--foo", help="foo", action='store_const') Traceback (most recent call last): File "", line 1, in File "/home/captain/projects/cpython/Lib/argparse.py", line 1350, in add_argument action = action_class(**kwargs) TypeError: __init__() missing 1 required positional argument: 'const' >>> Specifying the `const` argument stops this exception: >>> parser.add_argument("--foo", help="foo", action='store_const', const=None) _StoreConstAction(option_strings=['--foo'], dest='foo', nargs=0, const=None, default=None, type=None, choices=None, help='foo', metavar=None) Originally the docs, said when `action` was set to` 'store_const'` `const` defaulted to `None` which was not matching with the implementation at the time. After this commit : https://github.com/python/cpython/commi/b4912b8ed367e540ee060fe912f841cc764fd293, The docs were updated to match the implementation to fix Bpo issues : https://bugs.python.org/issue25299 https://bugs.python.org/issue24754 and https://bugs.python.org/issue25314 I suggest that we make `const` default to `None` If `action='store_const'` as was intended originally before edits to the docs. If no one objects, I can open a PR for this. ---------- messages: 349911 nosy: A. Skrobov, nanjekyejoannah, r.david.murray priority: normal severity: normal status: open title: For argparse add_argument with action='store_const', const should default to None. versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 20:42:03 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 18 Aug 2019 00:42:03 +0000 Subject: [issue25299] TypeError: __init__() takes at least 4 arguments (4 given) In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za> Message-ID: <1566088923.03.0.963829634816.issue25299@roundup.psfhosted.org> Joannah Nanjekye added the comment: Opened issue37880 to track this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 22:42:16 2019 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 18 Aug 2019 02:42:16 +0000 Subject: [issue37868] `is_dataclass` returns `True` if `getattr` always succeeds. In-Reply-To: <1565870535.54.0.93577990924.issue37868@roundup.psfhosted.org> Message-ID: <1566096136.97.0.819406671842.issue37868@roundup.psfhosted.org> Change by Eric V. Smith : ---------- keywords: +patch pull_requests: +15042 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15325 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 23:09:58 2019 From: report at bugs.python.org (Brendan Barnwell) Date: Sun, 18 Aug 2019 03:09:58 +0000 Subject: [issue16697] argparse kwarg 'choices' documentation In-Reply-To: <1355666035.13.0.877787561314.issue16697@psf.upfronthosting.co.za> Message-ID: <1566097798.05.0.0871166017723.issue16697@roundup.psfhosted.org> Brendan Barnwell added the comment: This issue has sat idle for six years. Meanwhile, the docs are still incorrect, giving every user wrong information about how the module works. Can we consider just changing the documentation instead of worrying about what the behavior should be or what the rationale is? ---------- nosy: +BrenBarn versions: +Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 23:10:23 2019 From: report at bugs.python.org (Brendan Barnwell) Date: Sun, 18 Aug 2019 03:10:23 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1566097823.66.0.525751847889.issue16468@roundup.psfhosted.org> Brendan Barnwell added the comment: https://bugs.python.org/issue16468 ---------- nosy: +BrenBarn versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 23:11:04 2019 From: report at bugs.python.org (Brendan Barnwell) Date: Sun, 18 Aug 2019 03:11:04 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1566097864.38.0.0967204971343.issue16468@roundup.psfhosted.org> Brendan Barnwell added the comment: This issue has sat idle for six years. Meanwhile, the docs are still incorrect, giving every user wrong information about how the module works. Can we consider just changing the documentation instead of worrying about what the behavior should be or what the rationale is? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 17 23:57:39 2019 From: report at bugs.python.org (Tim Peters) Date: Sun, 18 Aug 2019 03:57:39 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1566100659.83.0.530804052849.issue37863@roundup.psfhosted.org> Tim Peters added the comment: Some random notes: - 1425089352415399815 appears to be derived from using the golden ratio to contrive a worst case for the Euclid egcd method. Which it's good at :-) Even so, the current code runs well over twice as fast as when replacing the pow(that, -1, P) with pow(that, P-2, P). - Using binary gcd on the same thing requires only 46 iterations - and, of course, no divisions at all. So that could be a big win. There's no possible way to get exponentiation to require less than 60 iterations, because it requires that many squarings just to reach the high bit of P-2. However, I never finishing working out how to extend binary gcd to return inverses too. - All cases are "bad" for pow(whatever, P-2, P) because P-2 has 60 bits set. So we currently need 60 multiplies to account for those, in addition to 60 squarings to reach P-2's high bit. A significant speedup could probably have been gotten just by rewriting whatever**(P-2) as (whatever ** 79511827903920481) ** 29 That is, express P-2 as its prime factorization. There are 28 zero bits in the larger factor, so would save 28 multiply steps right there. Don't know how far that may yet be from an optimal addition chain for P-2. - The worst burden of the P-2-power method is that there's no convenient way to exploit that % P _can_ be very cheap, because P has a very special value. The power method actually needs to divide by P on each step. As currently coded, the egcd method never needs to divide by P (although _in_ the egcd part it divides narrower & narrower numbers < P). - Something on my todo list forever was writing an internal routine for squaring, based on that (a+b)**2 = a**2 + 2ab + b**2. That gives Karatsuba-like O() speedup but with simpler code, enough simpler that it could probably be profitably applied even to a relatively small argument. Which of those do I intend to pursue? Probably none :-( But I confess to be _annoyed_ at giving up on extending binary gcd to compute an inverse, so I may at least do that in Python before I die ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 02:57:48 2019 From: report at bugs.python.org (Ilya Konstantinov) Date: Sun, 18 Aug 2019 06:57:48 +0000 Subject: [issue35748] urlparse library detecting wrong hostname leads to open redirect vulnerability In-Reply-To: <1547624725.28.0.16631607093.issue35748@roundup.psfhosted.org> Message-ID: <1566111468.66.0.440908406399.issue35748@roundup.psfhosted.org> Ilya Konstantinov added the comment: >From RFC-1738: hostname = *[ domainlabel "." ] toplabel domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit alphadigit = alpha | digit However: py> urlparse('https://foo\\bar/baz') ParseResult(scheme='https', netloc='foo\\bar', path='/baz', params='', query='', fragment='') The hostname's BNF doesn't allow for a backslash ('\\') character, so I'd expect urlparse to raise a ValueError for this "URL". ---------- nosy: +Ilya Konstantinov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 05:49:57 2019 From: report at bugs.python.org (rdb) Date: Sun, 18 Aug 2019 09:49:57 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566121797.0.0.496057154879.issue37664@roundup.psfhosted.org> rdb added the comment: @steve.dower It will be necessary to update to pip 19.2.3 for Python 3.8.0b4 shortly, as per: https://github.com/pypa/pip/pull/6874#issuecomment-522220364 ---------- nosy: +rdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 06:11:20 2019 From: report at bugs.python.org (Hansraj Das) Date: Sun, 18 Aug 2019 10:11:20 +0000 Subject: [issue37543] Optimize pymalloc for non PGO build In-Reply-To: <1562756394.12.0.431999649056.issue37543@roundup.psfhosted.org> Message-ID: <1566123080.12.0.902038162158.issue37543@roundup.psfhosted.org> Change by Hansraj Das : ---------- pull_requests: +15043 pull_request: https://github.com/python/cpython/pull/15309 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 09:13:41 2019 From: report at bugs.python.org (Roundup Robot) Date: Sun, 18 Aug 2019 13:13:41 +0000 Subject: [issue32689] shutil.move raises AttributeError if first argument is a pathlib.Path object and destination is a directory In-Reply-To: <1517097684.51.0.467229070634.issue32689@psf.upfronthosting.co.za> Message-ID: <1566134021.69.0.0296851509698.issue32689@roundup.psfhosted.org> Change by Roundup Robot : ---------- pull_requests: +15044 pull_request: https://github.com/python/cpython/pull/15326 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 09:33:56 2019 From: report at bugs.python.org (Antony Lee) Date: Sun, 18 Aug 2019 13:33:56 +0000 Subject: [issue37881] __text_signature__ parser doesn't handle globals in extension module Message-ID: <1566135236.59.0.315734223996.issue37881@roundup.psfhosted.org> New submission from Antony Lee : Starting from the custom2 example at https://docs.python.org/3/extending/newtypes_tutorial.html#adding-data-and-methods-to-the-basic-example, change the methods table to static PyMethodDef Custom_methods[] = { {"foo", (PyCFunction) Custom_foo, METH_VARARGS, "foo(x=ONE)\n--\n\nFoos this." }, {NULL} /* Sentinel */ }; and add a global ONE to the module dict: PyModule_AddObject(m, "ONE", PyLong_FromLong(1)); Building and running e.g. pydoc on this module results in Traceback (most recent call last): File ".../lib/python3.7/inspect.py", line 2003, in wrap_value value = eval(s, module_dict) File "", line 1, in NameError: name 'ONE' is not defined During handling of the above exception, another exception occurred: Traceback (most recent call last): File ".../lib/python3.7/inspect.py", line 2006, in wrap_value value = eval(s, sys_module_dict) File "", line 1, in NameError: name 'ONE' is not defined During handling of the above exception, another exception occurred: Traceback (most recent call last): File ".../lib/python3.7/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File ".../lib/python3.7/inspect.py", line 2008, in wrap_value raise RuntimeError() RuntimeError I think the fix is fairly simple; one needs to replace module_name = getattr(obj, '__module__', None) in inspect.py::_signature_fromstr by module_name = (getattr(obj, '__module__', None) or getattr(getattr(obj, '__objclass__'), '__module__', None)) (This is a less general but simpler solution than https://bugs.python.org/issue23967.) ---------- components: Extension Modules messages: 349919 nosy: Antony.Lee priority: normal severity: normal status: open title: __text_signature__ parser doesn't handle globals in extension module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 12:39:49 2019 From: report at bugs.python.org (hai shi) Date: Sun, 18 Aug 2019 16:39:49 +0000 Subject: [issue9350] add remove_argument_group to argparse In-Reply-To: <1279893088.18.0.675631346333.issue9350@psf.upfronthosting.co.za> Message-ID: <1566146389.3.0.13503042175.issue9350@roundup.psfhosted.org> hai shi added the comment: IMHO, if we supply the ability to add an argument group, we need add the ability to remove the argument group too. ---------- nosy: +shihai1991 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 13:33:40 2019 From: report at bugs.python.org (paul j3) Date: Sun, 18 Aug 2019 17:33:40 +0000 Subject: [issue9350] add remove_argument_group to argparse In-Reply-To: <1279893088.18.0.675631346333.issue9350@psf.upfronthosting.co.za> Message-ID: <1566149620.34.0.585344247461.issue9350@roundup.psfhosted.org> paul j3 added the comment: hai shi Do you have a specific need for this, or do you want it just for the same of completeness? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 13:46:51 2019 From: report at bugs.python.org (George Zhang) Date: Sun, 18 Aug 2019 17:46:51 +0000 Subject: [issue37882] Code folding in IDLE Message-ID: <1566150411.87.0.37054908058.issue37882@roundup.psfhosted.org> New submission from George Zhang : Congrats on adding line numbers to IDLE. With this change, a change to add code folding could be done more easily as the folding can reference the line numbers. Many other IDEs have code folding but IDLE should also have it. Code folding could be done with a +/- to the right of the line numbers and can show/hide the indented suite under the header (compound statements). It should use indentation as tool to figure out which parts can be folded. Blank lines don't count. Single line compound statements cannot be folded. Something like this: 1 - | def spam(ham): 2 - | if ham: 3 | eggs() 4 | 5 + | def frob(): 8 | 9 - | FOO = ( 10 | 1, 2, 3, 4, 11 | 5, 6, 7, 8, 12 | ) 13 | 14 | BAR = ( 17 | ) 18 | 19 | if True: print("True") 20 | ---------- assignee: terry.reedy components: IDLE messages: 349922 nosy: GeeVye, terry.reedy priority: normal severity: normal status: open title: Code folding in IDLE versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 13:47:01 2019 From: report at bugs.python.org (George Zhang) Date: Sun, 18 Aug 2019 17:47:01 +0000 Subject: [issue37882] Code folding in IDLE In-Reply-To: <1566150411.87.0.37054908058.issue37882@roundup.psfhosted.org> Message-ID: <1566150421.11.0.0487557830756.issue37882@roundup.psfhosted.org> Change by George Zhang : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 14:14:23 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 18 Aug 2019 18:14:23 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1566152063.08.0.0951966193913.issue16468@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 14:36:18 2019 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=) Date: Sun, 18 Aug 2019 18:36:18 +0000 Subject: [issue37883] threading.Lock.locked is not documented Message-ID: <1566153378.15.0.0440090654943.issue37883@roundup.psfhosted.org> New submission from R?mi Lapeyre : As far as I can tell, it has never been documented. I'm not sure if it is deprecated but it has a docstring so it seems to me, that it just needs documentation in Doc/Library/threading.rst PS: I don't know how to set the beginner friendly flag. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 349923 nosy: docs at python, remi.lapeyre priority: normal severity: normal status: open title: threading.Lock.locked is not documented type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 15:14:51 2019 From: report at bugs.python.org (paul j3) Date: Sun, 18 Aug 2019 19:14:51 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1566155691.75.0.883414082935.issue16468@roundup.psfhosted.org> paul j3 added the comment: But see https://bugs.python.org/issue37793 for a discussion of whether 'container' is as good a descriptor as 'iterable'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 16:44:54 2019 From: report at bugs.python.org (SilentGhost) Date: Sun, 18 Aug 2019 20:44:54 +0000 Subject: [issue37882] Code folding in IDLE In-Reply-To: <1566150411.87.0.37054908058.issue37882@roundup.psfhosted.org> Message-ID: <1566161094.33.0.620390346689.issue37882@roundup.psfhosted.org> Change by SilentGhost : ---------- versions: -Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 17:02:37 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 18 Aug 2019 21:02:37 +0000 Subject: [issue37882] Code folding in IDLE In-Reply-To: <1566150411.87.0.37054908058.issue37882@roundup.psfhosted.org> Message-ID: <1566162157.58.0.418538498191.issue37882@roundup.psfhosted.org> Terry J. Reedy added the comment: I am familiar with the feature in Notepad++ on Windows. But I never use its +- code folding. IDLE already has two different and, to me, generally better code folding features. To get an outline view of a file's classes and functions, use File => Module Browser or its shortcut. One can selectively expand any item with nested class and function definitions. Such multilevel outline views are not possible with Notepad++, as [+] mean expands completely, not just nested definitions. I suspect that this is generally true of IDEs with marginal -+. [Module browser can still be improved, such as by processing the code in an editor buffer instead of on disk, and updating automatically, but that is a different issue.] One can instead get a dynamic view of nested compound statement headers with Options => Code Context. Look at any file longer than the editor window with nested compound statements, such as idlelib/editor.py. This feature is impossible with all or nothing -+ collapse. There may be other use cases, but then we have a major technical problem. Tk Text widgets do not support code folding. They have no method to hide lines in their text buffers. Nor, as far as I know, is there any workaround with a 'Hide' tag. Tk fonts have no 'visible' option. Font size 1 or -1 is not 0, and size 0 is interpreted as a some default, around 15. So hidden lines would have to be deleted. The easiest option might be a dictionary mapping tk line numbers to lists of deleted lines and another function and data structure to map tk line numbers to the line numbers needed for display. Doing this without introducing bugs would be non-trivial. I would not consider this unless there were a strong use case that would greatly benefit *and* be used by beginners. Silent Ghost> This is an IDLE issue. If this were added, which is extremely unlikely, it would be backported, just as line numbers were. (See PEP 434.) It does not really matter which versions are marked here by the OP. ---------- versions: +Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 17:08:46 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Sun, 18 Aug 2019 21:08:46 +0000 Subject: [issue37836] Support .as_integer_ratio() in fractions.Fraction In-Reply-To: <1565689279.74.0.17922836333.issue37836@roundup.psfhosted.org> Message-ID: <1566162526.34.0.605529909058.issue37836@roundup.psfhosted.org> Change by Jeroen Demeyer : ---------- keywords: +patch pull_requests: +15045 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15327 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 17:41:06 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Sun, 18 Aug 2019 21:41:06 +0000 Subject: [issue37836] Support .as_integer_ratio() in fractions.Fraction In-Reply-To: <1565689279.74.0.17922836333.issue37836@roundup.psfhosted.org> Message-ID: <1566164466.34.0.381346653812.issue37836@roundup.psfhosted.org> Change by Jeroen Demeyer : ---------- pull_requests: +15046 pull_request: https://github.com/python/cpython/pull/15328 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 17:49:41 2019 From: report at bugs.python.org (Thibault Molleman) Date: Sun, 18 Aug 2019 21:49:41 +0000 Subject: [issue34529] add the option for json.dumps to return newline delimited json In-Reply-To: <1535460432.73.0.56676864532.issue34529@psf.upfronthosting.co.za> Message-ID: <1566164981.61.0.65391668902.issue34529@roundup.psfhosted.org> Change by Thibault Molleman : ---------- nosy: +Thibault Molleman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 18:22:47 2019 From: report at bugs.python.org (Tim Peters) Date: Sun, 18 Aug 2019 22:22:47 +0000 Subject: [issue37863] Speed up hash(fractions.Fraction) In-Reply-To: <1565836245.18.0.379877186731.issue37863@roundup.psfhosted.org> Message-ID: <1566166967.45.0.868814849661.issue37863@roundup.psfhosted.org> Tim Peters added the comment: For posterity: "Modular Inverse Algorithms Without Multiplications for Cryptographic Applications" Laszlo Hars https://link.springer.com/article/10.1155/ES/2006/32192 """ On the considered computational platforms for operand lengths used in cryptography, the fastest presented modular inverse algorithms need about twice the time of modular multiplications, or even less. """ Lars considered a great many algorithm variations, and wrote up about ten of the best. Several things surprised me here. Most surprising: under some realistic assumptions, _the_ best turned out to be a relatively simple variation of Euclid extended GCD. Nutshell: during a step, let the difference between the bit lengths of the then-current numerator and denominator be `f`. Then look at a few leading bits to pick whichever of `s` in {f-1, f, f+1} will clear the largest handful of leading bits in `numerator - (denominator << s)` (this test is meant to be fast, not exact - it's a refinement of an easier variant that just picks s=f). The "quotient" in this step is then 2**s, and the rest is shifting and adding/subtracting. No division or multiplication is needed. This has a larger expected iteration count than some other methods, but, like regular old Euclid GCD, needs relatively little code per iteration. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 19:50:11 2019 From: report at bugs.python.org (Andrew Frost) Date: Sun, 18 Aug 2019 23:50:11 +0000 Subject: [issue7982] extend captured_output to simulate different stdout.encoding In-Reply-To: <1266844157.92.0.671833558035.issue7982@psf.upfronthosting.co.za> Message-ID: <1566172211.43.0.121865113123.issue7982@roundup.psfhosted.org> Andrew Frost added the comment: The patch Berker attached back in 2014 was never added to Python, I'd like to submit a PR for it as my first Python contribution! ---------- nosy: +adfrost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 20:42:05 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 Aug 2019 00:42:05 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1566175325.5.0.408285902965.issue16468@roundup.psfhosted.org> Raymond Hettinger added the comment: I think this should be dropped. IMO it is a pedantic nit. There is the everyday usage of the word "container" which has a reasonable plain meaning. There is also an ABC that was unfortunately called Container (with a capital C) that means anything the defines __contains__. IMO, we don't have to change all uses for the former just because the latter exists. AFAICT, this "issue" for the argparse has never been a real problem for a real user ever in the entire history of the module. So, unless there are strong objections, I would like to close this and we can shift our attention to matters of actual importance. ---------- assignee: -> rhettinger nosy: +rhettinger versions: +Python 3.9 -Python 2.7, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 20:47:11 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 Aug 2019 00:47:11 +0000 Subject: [issue9350] add remove_argument_group to argparse In-Reply-To: <1279893088.18.0.675631346333.issue9350@psf.upfronthosting.co.za> Message-ID: <1566175631.92.0.0573728166636.issue9350@roundup.psfhosted.org> Raymond Hettinger added the comment: > The use case for me is I create an argument group and > then conditionally add a bunch of arguments to it. > If zero arguments are added I would like to then remove > the group so that an empty group does not show up > in the help output. ISTM this use is likely rare enough that it doesn't warrant an API expansion. The argparse API is already somewhat large, so we should only expand it when there is a compelling benefit or the absence of a reasonable workaround (i.e. lazily adding a group only when the first argument is added). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 20:49:47 2019 From: report at bugs.python.org (Brendan Barnwell) Date: Mon, 19 Aug 2019 00:49:47 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1566175787.4.0.432878502654.issue16468@roundup.psfhosted.org> Brendan Barnwell added the comment: Here is an example of someone who cares about the behavior and/or the documentation (and still cares enough to check up on their StackOverflow question six years later): https://stackoverflow.com/questions/13833566/python-argparse-choices-from-an-infinite-set/13833736 . The issue is not the use of the word "container". The docs literally say "Any object that supports the `in` operator can be passed as the choices value" and that is not true. In fact, changing it to say "any container type" would be an improvement as that is at least arguably correct, whereas the current documentation is unambiguously incorrect. ---------- versions: -Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 18 22:20:34 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 19 Aug 2019 02:20:34 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566181234.54.0.196674029762.issue37664@roundup.psfhosted.org> Inada Naoki added the comment: When updating pip next time, please update setuptools too. https://setuptools.readthedocs.io/en/latest/history.html#v41-1-0 > #1788: Changed compatibility fallback logic for html.unescape to avoid accessing HTMLParser.unescape when not necessary. HTMLParser.unescape is deprecated and will be removed in Python 3.9. This is blocking #37328. ---------- nosy: +inada.naoki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 00:39:55 2019 From: report at bugs.python.org (hai shi) Date: Mon, 19 Aug 2019 04:39:55 +0000 Subject: [issue9350] add remove_argument_group to argparse In-Reply-To: <1279893088.18.0.675631346333.issue9350@psf.upfronthosting.co.za> Message-ID: <1566189595.41.0.613609632785.issue9350@roundup.psfhosted.org> hai shi added the comment: paul, raymond. Thanks for give me a quick answer:). Looks raymond's reason is good enough, i just only consider this question from api completeness(as paul said) not from user case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 01:02:46 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 19 Aug 2019 05:02:46 +0000 Subject: [issue37836] Support .as_integer_ratio() in fractions.Fraction In-Reply-To: <1565689279.74.0.17922836333.issue37836@roundup.psfhosted.org> Message-ID: <1566190966.7.0.880086315749.issue37836@roundup.psfhosted.org> Serhiy Storchaka added the comment: I afraid this can slow down the Fraction constructor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 01:30:56 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 Aug 2019 05:30:56 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1566192656.46.0.491451072348.issue16468@roundup.psfhosted.org> Raymond Hettinger added the comment: Okay, that makes sense. Go ahead with the edit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 01:33:35 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 Aug 2019 05:33:35 +0000 Subject: [issue37882] Code folding in IDLE In-Reply-To: <1566150411.87.0.37054908058.issue37882@roundup.psfhosted.org> Message-ID: <1566192815.67.0.722394149417.issue37882@roundup.psfhosted.org> Raymond Hettinger added the comment: Terry, you've made a good case that this feature request should be closed. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 01:37:40 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 19 Aug 2019 05:37:40 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1566193060.7.0.0198443532009.issue37819@roundup.psfhosted.org> Serhiy Storchaka added the comment: Sorry, but I do not understand why adding Fraction.as_integer_ratio() prevents adding math.as_integer_ratio(). The user code can not benefit from this until we add as_integer_ratio() to all numeric numbers, and this is not realistic. For the same reason there is str.join() which works with arbitrary iterable instead of adding the join() method to all collections, iterators and generators. math.as_integer_ratio() makes the user code more general, clear and fast. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 01:54:24 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 19 Aug 2019 05:54:24 +0000 Subject: [issue37862] Search doesn't find built-in functions In-Reply-To: <1565831586.7.0.196033639625.issue37862@roundup.psfhosted.org> Message-ID: <1566194064.42.0.539715834014.issue37862@roundup.psfhosted.org> Terry J. Reedy added the comment: The search page is the last thing one should use. There is the index https://docs.python.org/3/genindex-Z.html and for builtin function, chapter 2 of the library manual. https://docs.python.org/3/library/functions.html#built-in-functions I don't know if the operation of the search page is documented anytwhere. ---------- nosy: +terry.reedy versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 02:03:39 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 19 Aug 2019 06:03:39 +0000 Subject: [issue37873] unittest: execute tests in parallel In-Reply-To: <1565964928.02.0.804836557192.issue37873@roundup.psfhosted.org> Message-ID: <1566194619.39.0.982742593728.issue37873@roundup.psfhosted.org> Terry J. Reedy added the comment: test.regrtest has a -j option. Perhaps some of the Python coding for that could be used for unitest also. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 02:03:56 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 19 Aug 2019 06:03:56 +0000 Subject: [issue37873] unittest: execute tests in parallel In-Reply-To: <1565964928.02.0.804836557192.issue37873@roundup.psfhosted.org> Message-ID: <1566194636.04.0.976873437027.issue37873@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- nosy: +ezio.melotti, michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 02:17:30 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 19 Aug 2019 06:17:30 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() Message-ID: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> New submission from Serhiy Storchaka : The proposed PR optimizes the Fraction constructor and statistics.mean() (and several other statistics functions) by using a private helper implemented in C which abstracts converting a number to an integer ratio. $ ./python -m timeit -s "from fractions import Fraction as F" "F(123)" 500000 loops, best of 5: 655 nsec per loop 500000 loops, best of 5: 749 nsec per loop $ ./python -m timeit -s "from fractions import Fraction as F" "F(1.23)" 200000 loops, best of 5: 1.29 usec per loop 200000 loops, best of 5: 1.03 usec per loop $ ./python -m timeit -s "from fractions import Fraction as F; f = F(22, 7)" "F(f)" 200000 loops, best of 5: 1.17 usec per loop 500000 loops, best of 5: 899 nsec per loop $ ./python -m timeit -s "from fractions import Fraction as F; from decimal import Decimal as D; d = D('1.23')" "F(d)" 200000 loops, best of 5: 1.64 usec per loop 200000 loops, best of 5: 1.29 usec per loop $ ./python -m timeit -s "from statistics import mean; a = [1]*1000" "mean(a)" 500 loops, best of 5: 456 usec per loop 1000 loops, best of 5: 321 usec per loop $ ./python -m timeit -s "from statistics import mean; a = [1.23]*1000" "mean(a)" 500 loops, best of 5: 645 usec per loop 500 loops, best of 5: 659 usec per loop $ ./python -m timeit -s "from statistics import mean; from fractions import Fraction as F; a = [F(22, 7)]*1000" "mean(a)" 500 loops, best of 5: 637 usec per loop 500 loops, best of 5: 490 usec per loop $ ./python -m timeit -s "from statistics import mean; from decimal import Decimal as D; a = [D('1.23')]*1000" "mean(a)" 500 loops, best of 5: 946 usec per loop 500 loops, best of 5: 915 usec per loop There is a 14% regression in creating a Fraction from an integer, but for non-integer numbers it gains 25% speed up. The effect on statistics.mean() varies from insignificant to +40%. ---------- components: Library (Lib) messages: 349939 nosy: mark.dickinson, rhettinger, serhiy.storchaka, steven.daprano priority: normal severity: normal status: open title: Optimize Fraction() and statistics.mean() type: performance versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 02:19:00 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 19 Aug 2019 06:19:00 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566195540.71.0.313537333541.issue37884@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +15047 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15329 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 02:20:20 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 19 Aug 2019 06:20:20 +0000 Subject: [issue37836] Support .as_integer_ratio() in fractions.Fraction In-Reply-To: <1565689279.74.0.17922836333.issue37836@roundup.psfhosted.org> Message-ID: <1566195620.79.0.10665801911.issue37836@roundup.psfhosted.org> Serhiy Storchaka added the comment: See issue37884 which uses a C accelerator. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 04:28:15 2019 From: report at bugs.python.org (Pradyun Gedam) Date: Mon, 19 Aug 2019 08:28:15 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1566181234.54.0.196674029762.issue37664@roundup.psfhosted.org> Message-ID: Pradyun Gedam added the comment: There wasn't a new setuptools release when I updated these the last time, IIRC. Anyway, I'll cut a new release for pip, file a new b.p.o. issue and get to updating both of these sometime this week. On Mon, 19 Aug 2019 at 11:20 AM, Inada Naoki wrote: > > Inada Naoki added the comment: > > When updating pip next time, please update setuptools too. > https://setuptools.readthedocs.io/en/latest/history.html#v41-1-0 > > > #1788: Changed compatibility fallback logic for html.unescape to avoid > accessing HTMLParser.unescape when not necessary. HTMLParser.unescape is > deprecated and will be removed in Python 3.9. > > This is blocking #37328. > > ---------- > nosy: +inada.naoki > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 04:36:44 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Mon, 19 Aug 2019 08:36:44 +0000 Subject: [issue37836] Support .as_integer_ratio() in fractions.Fraction In-Reply-To: <1565689279.74.0.17922836333.issue37836@roundup.psfhosted.org> Message-ID: <1566203804.32.0.57270564628.issue37836@roundup.psfhosted.org> Jeroen Demeyer added the comment: > See issue37884 which uses a C accelerator. Note that that doesn't replace this issue, because I need to support as_integer_ratio both in the *numerator* and *denominator*. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 04:37:37 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Mon, 19 Aug 2019 08:37:37 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566203857.37.0.4024367137.issue37884@roundup.psfhosted.org> Jeroen Demeyer added the comment: > There is a 14% regression in creating a Fraction from an integer Isn't that the main use case? I suggest to keep the special case for 'int' as fast path to avoid this regression. ---------- nosy: +jdemeyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 04:50:09 2019 From: report at bugs.python.org (Daniel Abrahamsson) Date: Mon, 19 Aug 2019 08:50:09 +0000 Subject: [issue37885] venv: Don't produce unbound variable warning on deactivate Message-ID: <1566204609.23.0.435399494767.issue37885@roundup.psfhosted.org> New submission from Daniel Abrahamsson : Running deactivate from a bash shell configured to treat undefined variables as errors (`set -u`) produces a warning: ``` $ python3 -m venv test $ source test/bin/activate (test) $ deactivate -bash: $1: unbound variable ``` ---------- components: Library (Lib) messages: 349944 nosy: danabr priority: normal severity: normal status: open title: venv: Don't produce unbound variable warning on deactivate type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 04:51:28 2019 From: report at bugs.python.org (Daniel Abrahamsson) Date: Mon, 19 Aug 2019 08:51:28 +0000 Subject: [issue37885] venv: Don't produce unbound variable warning on deactivate In-Reply-To: <1566204609.23.0.435399494767.issue37885@roundup.psfhosted.org> Message-ID: <1566204688.76.0.531716227156.issue37885@roundup.psfhosted.org> Change by Daniel Abrahamsson : ---------- keywords: +patch pull_requests: +15048 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15330 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 05:08:06 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Mon, 19 Aug 2019 09:08:06 +0000 Subject: [issue37836] Support .as_integer_ratio() in fractions.Fraction In-Reply-To: <1565689279.74.0.17922836333.issue37836@roundup.psfhosted.org> Message-ID: <1566205686.32.0.191589220181.issue37836@roundup.psfhosted.org> Jeroen Demeyer added the comment: > I afraid this can slow down the Fraction constructor. No, it doesn't! It even speeds up the constructor in some cases: ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = 1' 'Fraction(x)' BEFORE: Mean +- std dev: 826 ns +- 20 ns AFTER: Mean +- std dev: 814 ns +- 17 ns ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = 1' 'Fraction(x, x)' BEFORE: Mean +- std dev: 1.44 us +- 0.03 us AFTER: Mean +- std dev: 1.46 us +- 0.02 us ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = Fraction(1)' 'Fraction(x)' BEFORE: Mean +- std dev: 1.64 us +- 0.03 us AFTER: Mean +- std dev: 1.30 us +- 0.04 us ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = Fraction(1)' 'Fraction(x, x)' BEFORE: Mean +- std dev: 3.03 us +- 0.05 us AFTER: Mean +- std dev: 2.34 us +- 0.06 us ./python -m perf timeit --duplicate 200 -s 'from fractions import Fraction; x = 1.0' 'Fraction(x)' BEFORE: Mean +- std dev: 1.82 us +- 0.02 us AFTER: Mean +- std dev: 1.29 us +- 0.04 us ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 05:17:27 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Mon, 19 Aug 2019 09:17:27 +0000 Subject: [issue37819] as_integer_ratio() missing from fractions.Fraction() In-Reply-To: <1565506913.18.0.756689678567.issue37819@roundup.psfhosted.org> Message-ID: <1566206247.65.0.60768024508.issue37819@roundup.psfhosted.org> Jeroen Demeyer added the comment: > Sorry, but I do not understand why adding Fraction.as_integer_ratio() prevents adding math.as_integer_ratio(). I also support a public function for that. It seems that we're planning this "as_integer_ratio" thing to become public API, so why not have a function as Serhiy proposes? I consider the situation with as_integer_ratio() very analogous to __index__ where we have operator.index(), so I would actually suggest operator.as_integer_ratio() but that's bikeshedding territory. ---------- nosy: +jdemeyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 05:53:40 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 09:53:40 +0000 Subject: [issue36502] str.isspace() for U+00A0 and U+202F differs from document In-Reply-To: <1554186967.56.0.21483381742.issue36502@roundup.psfhosted.org> Message-ID: <1566208420.83.0.209995676503.issue36502@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 8c1c426a631ba02357112657193f82c58d3e08b4 by Victor Stinner (Greg Price) in branch '3.8': bpo-36502: Correct documentation of str.isspace() (GH-15019) (GH-15296) https://github.com/python/cpython/commit/8c1c426a631ba02357112657193f82c58d3e08b4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 05:53:53 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 19 Aug 2019 09:53:53 +0000 Subject: [issue36502] str.isspace() for U+00A0 and U+202F differs from document In-Reply-To: <1554186967.56.0.21483381742.issue36502@roundup.psfhosted.org> Message-ID: <1566208433.35.0.734879517354.issue36502@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15050 pull_request: https://github.com/python/cpython/pull/15332 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 06:10:23 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 19 Aug 2019 10:10:23 +0000 Subject: [issue36502] str.isspace() for U+00A0 and U+202F differs from document In-Reply-To: <1554186967.56.0.21483381742.issue36502@roundup.psfhosted.org> Message-ID: <1566209423.31.0.212187671723.issue36502@roundup.psfhosted.org> miss-islington added the comment: New changeset 0fcdd8d6d67f57733203fc79e6a07a89b924a390 by Miss Islington (bot) in branch '3.7': bpo-36502: Correct documentation of str.isspace() (GH-15019) (GH-15296) https://github.com/python/cpython/commit/0fcdd8d6d67f57733203fc79e6a07a89b924a390 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 06:13:40 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 10:13:40 +0000 Subject: [issue21131] test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 In-Reply-To: <1396430238.51.0.283909097168.issue21131@psf.upfronthosting.co.za> Message-ID: <1566209620.77.0.332029074062.issue21131@roundup.psfhosted.org> STINNER Victor added the comment: > Its interesting to read the comment on the IA64 definition for SIGSTKSZ: Python doesn't support IA64 architecture. Note: I'm not sure that this architecture is going to survive in the long term... More and more systems stopped to support it. > Well, one argument for the dynamic approach is that existing python binaries can adjust without needing to be respun for new CPUs. PR 13649 gets the default thread stack size, it doesn't get SIGSTKSZ. I expect a thread stack size to be way larger than SIGSTKSZ. For on my Fedora 30 (Linux kernel 5.1.19-300.fc30.x86_64, glibc-2.29-15.fc30.x86_64) on x86-64, SIGSTKSZ is just 8 KiB (8192 bytes) whereas pthread_attr_getstacksize() returns 8 MiB (8388608 bytes). As I already wrote, using 8 MiB instead of 8 KiB looks like a waste of memory: faulthandler is only useful for stack overflow, which is a very unlikely bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 06:14:33 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 10:14:33 +0000 Subject: [issue36502] str.isspace() for U+00A0 and U+202F differs from document In-Reply-To: <1554186967.56.0.21483381742.issue36502@roundup.psfhosted.org> Message-ID: <1566209673.44.0.880809431233.issue36502@roundup.psfhosted.org> STINNER Victor added the comment: str.isspace() documentation has been fixed, thanks Greg Price for the fix! I close the issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 06:15:34 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 10:15:34 +0000 Subject: [issue37869] Compilation warning on GCC version 7.4.0-1ubuntu1~18.04.1 In-Reply-To: <1565901041.74.0.0939495038375.issue37869@roundup.psfhosted.org> Message-ID: <1566209734.9.0.513358892304.issue37869@roundup.psfhosted.org> Change by STINNER Victor : ---------- stage: -> resolved status: open -> closed superseder: -> Possible uninitialized variable in Objects/obmalloc.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 06:15:42 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 10:15:42 +0000 Subject: [issue37869] Compilation warning on GCC version 7.4.0-1ubuntu1~18.04.1 In-Reply-To: <1565901041.74.0.0939495038375.issue37869@roundup.psfhosted.org> Message-ID: <1566209742.57.0.878509656196.issue37869@roundup.psfhosted.org> STINNER Victor added the comment: Duplicate of bpo-37732. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 06:15:57 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 10:15:57 +0000 Subject: [issue37732] Possible uninitialized variable in Objects/obmalloc.c In-Reply-To: <1564582636.59.0.312005293129.issue37732@roundup.psfhosted.org> Message-ID: <1566209757.58.0.659108936619.issue37732@roundup.psfhosted.org> STINNER Victor added the comment: bpo-37869 has been marked as a duplicate of this issue. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 06:27:13 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 10:27:13 +0000 Subject: [issue37732] Possible uninitialized variable in Objects/obmalloc.c In-Reply-To: <1564582636.59.0.312005293129.issue37732@roundup.psfhosted.org> Message-ID: <1566210433.92.0.771055924423.issue37732@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15051 pull_request: https://github.com/python/cpython/pull/15333 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 06:30:41 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 10:30:41 +0000 Subject: [issue18835] Add PyMem_AlignedAlloc() In-Reply-To: <1377484371.18.0.399621580043.issue18835@psf.upfronthosting.co.za> Message-ID: <1566210641.51.0.881748127275.issue18835@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15052 pull_request: https://github.com/python/cpython/pull/15333 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 06:35:01 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 10:35:01 +0000 Subject: [issue37565] test_faulthandler: test_register_chain() crash with SIGSEGV (signal 11) on Skylake chipset In-Reply-To: <1562857971.79.0.0137287316017.issue37565@roundup.psfhosted.org> Message-ID: <1566210901.57.0.811455528606.issue37565@roundup.psfhosted.org> STINNER Victor added the comment: Bennet Fauber: > It would appear that jshelly was correct and this is resolved by fixing the problem isolated in issue 21131, which was closed and a patch was committed. Great! I close this issue as a duplicate of bpo-21131. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> test_faulthandler.test_register_chain fails on 64bit ppc/arm with kernel >= 3.10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 06:40:00 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 10:40:00 +0000 Subject: [issue37878] Sub-Interpreters : Document PyThreadState_DeleteCurrent() In-Reply-To: <1565985235.6.0.212314052144.issue37878@roundup.psfhosted.org> Message-ID: <1566211200.15.0.534809978575.issue37878@roundup.psfhosted.org> STINNER Victor added the comment: I'm not sure why PyThreadState_DeleteCurrent() is exposed. Why would anyone use it? It is used internally by the _thread module when the thread function completes. I suggest to make the function internal instead of documenting it. Eric, Joannah: what do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 06:43:17 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 10:43:17 +0000 Subject: [issue37866] PyModule_GetState Segmentation fault when called Py_Initialize In-Reply-To: <1565862147.92.0.832286772909.issue37866@roundup.psfhosted.org> Message-ID: <1566211397.69.0.528022033228.issue37866@roundup.psfhosted.org> STINNER Victor added the comment: Python 3.5 no longer accept bug fixes. Are you able to reproduce the bug with Python 3.8, or Python 3.7? > the crash file came out when i tried to call Py_Initialize in a C file. Can you provide this file? What is your OS and OS version? How did you install Python? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 08:43:49 2019 From: report at bugs.python.org (Jeff Robbins) Date: Mon, 19 Aug 2019 12:43:49 +0000 Subject: [issue37886] PyStructSequence_UnnamedField not exported Message-ID: <1566218629.27.0.381481574182.issue37886@roundup.psfhosted.org> New submission from Jeff Robbins : Python 3.8.0b3 has the fixed https://docs.python.org/3/c-api/tuple.html#c.PyStructSequence_NewType, but one of the documented features of PyStructSequence is the special https://docs.python.org/3/c-api/tuple.html#c.PyStructSequence_UnnamedField which is meant to be used for unnamed (and presumably also "hidden") fields. However, this variable is not "exported" (via __declspec(dllexport) or the relevant Python C macro) and so my C extension cannot "import" it and use it. My guess is that this passed testing because the only tests using it are internal modules linked into python38.dll, which are happy with the `extern` in the header: Include\structseq.h:extern char* PyStructSequence_UnnamedField; ---------- components: Windows messages: 349956 nosy: jeffr at livedata.com, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: PyStructSequence_UnnamedField not exported type: compile error versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 10:04:52 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 14:04:52 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1566223492.2.0.3203005732.issue34155@roundup.psfhosted.org> STINNER Victor added the comment: > Created a backport PR for 3.5. Thanks. I reviewed it (LGTM). What about Python 2.7, it's also vulnerable, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 10:32:54 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Mon, 19 Aug 2019 14:32:54 +0000 Subject: [issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class In-Reply-To: <1565689003.91.0.0312877377737.issue37835@roundup.psfhosted.org> Message-ID: <1566225174.05.0.911993697481.issue37835@roundup.psfhosted.org> Ivan Levkivskyi added the comment: Thanks for reporting! I spent some time thinking about this and I can't find any reasonable way of doing this, sorry. Anyway, let's keep this open, maybe someone will come up with a proposal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 10:55:03 2019 From: report at bugs.python.org (hai shi) Date: Mon, 19 Aug 2019 14:55:03 +0000 Subject: [issue37887] some leak in the compiler_assert function Message-ID: <1566226503.82.0.418800588376.issue37887@roundup.psfhosted.org> New submission from hai shi : Some reference leak in compiler_assert function, due to not using Py_DECREF(assertion_error) before return. And having a question about code order in compiler_assert function. ---------- components: Interpreter Core files: compiler_assert.patch keywords: patch messages: 349959 nosy: pitrou, shihai1991, vstinner priority: normal severity: normal status: open title: some leak in the compiler_assert function type: resource usage versions: Python 3.9 Added file: https://bugs.python.org/file48550/compiler_assert.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 11:31:01 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Mon, 19 Aug 2019 15:31:01 +0000 Subject: [issue37878] Sub-Interpreters : Document PyThreadState_DeleteCurrent() In-Reply-To: <1565985235.6.0.212314052144.issue37878@roundup.psfhosted.org> Message-ID: <1566228661.44.0.499997134577.issue37878@roundup.psfhosted.org> Joannah Nanjekye added the comment: >From what I know the GIL is released by calling PyEval_ReleaseThread() or PyEval_SaveThread(). I see we can use PyThreadState_Delete() to clean up-specifically destroy thread state but does not release the GIL and requires a thread state. On the other hand, PyThreadState_DeleteCurrent() allows to both clean up the current thread state - no thread state is required as well release the GIL which is convenient. I would not fight so much to keep it public given we have PyEval_ReleaseThread() or PyEval_SaveThread(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 11:54:06 2019 From: report at bugs.python.org (Jeff Robbins) Date: Mon, 19 Aug 2019 15:54:06 +0000 Subject: [issue37886] PyStructSequence_UnnamedField not exported In-Reply-To: <1566218629.27.0.381481574182.issue37886@roundup.psfhosted.org> Message-ID: <1566230046.05.0.52889742185.issue37886@roundup.psfhosted.org> Jeff Robbins added the comment: Editing one line in structseq.h seems to fix the issue. I changed this extern char* PyStructSequence_UnnamedField; to PyAPI_DATA(char*) PyStructSequence_UnnamedField; rebuilt, and now my C extension can use PyStructSequence_UnnamedField. ---------- Added file: https://bugs.python.org/file48551/structseq.h _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 14:12:10 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Mon, 19 Aug 2019 18:12:10 +0000 Subject: [issue37764] email.Message.as_string infinite loop In-Reply-To: <1565022203.43.0.680976058043.issue37764@roundup.psfhosted.org> Message-ID: <1566238330.62.0.762351571916.issue37764@roundup.psfhosted.org> Ashwin Ramaswami added the comment: Thanks, I've fixed the first case as you suggested. I found an example of the 2nd case -- '=?utf-8?q?=somevalue?=' -- which causes the method to hang. I've added a fix, though I'm not sure if it treats the string properly -- it parses it as '=?utf-8?q?=somevalue?=' and doesn't raise any defects. Is that the behavior we would want? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 14:29:25 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 Aug 2019 18:29:25 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566239365.64.0.498088569187.issue37884@roundup.psfhosted.org> Raymond Hettinger added the comment: Mark, I don't think the math module API should be expanded for as_integer_ratio(). ISTM that small and probably unimportant opimizations shouldn't spill-over into API feature creep. What do you think? ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 14:38:36 2019 From: report at bugs.python.org (Zachary Ware) Date: Mon, 19 Aug 2019 18:38:36 +0000 Subject: [issue37875] gzip module any difference for compressing png file in version 2.X and 3.X In-Reply-To: <1565967130.84.0.685308566342.issue37875@roundup.psfhosted.org> Message-ID: <1566239916.25.0.0570771177517.issue37875@roundup.psfhosted.org> Change by Zachary Ware : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 15:05:22 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Mon, 19 Aug 2019 19:05:22 +0000 Subject: [issue37888] Sub-interpreters : Confusing docs about state after calling Py_NewInterpreter() Message-ID: <1566241522.51.0.41054137805.issue37888@roundup.psfhosted.org> New submission from Joannah Nanjekye : In the documentation for Py_NewInterpreter(): It is said that : The return value points to the first thread state created in the new sub-interpreter. This thread state is made in the current thread state. I think changing : This thread state is made in the current thread state. To: This thread state is made the current thread state. Sounds good. Since a call such as: substate = Py_NewInterpreter() makes *substate* the current state. no? The *in* takes me in a different direction of thought. ---------- messages: 349964 nosy: nanjekyejoannah priority: normal severity: normal status: open title: Sub-interpreters : Confusing docs about state after calling Py_NewInterpreter() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 15:42:13 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Mon, 19 Aug 2019 19:42:13 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566243733.21.0.58197218341.issue37884@roundup.psfhosted.org> Jeroen Demeyer added the comment: > ISTM that small and probably unimportant opimizations shouldn't spill-over into API feature creep. The way I see it, the optimization is besides the point here. Regardless of performance, the added function is a useful feature to have to avoid forcing people to reinvent the wheel. For example, would you want the exact same code duplicated for fractions.Fraction() and for statictics.mean()? See also #37836 in case you didn't know about that issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 15:56:10 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 19 Aug 2019 19:56:10 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566244570.31.0.774571385743.issue37884@roundup.psfhosted.org> Serhiy Storchaka added the comment: This issue if for optimization only. It does not expand the math module API. Adding public math.as_integer_ratio() has other benefits (it allows to simplify the user code), but it is a different issue (see issue37822). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 16:00:36 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 19 Aug 2019 20:00:36 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566244836.25.0.850189493018.issue37884@roundup.psfhosted.org> Raymond Hettinger added the comment: AFAICT, no end-user has ever requested this ever. Despite your insistence, we really don't have to clutter the math module with this. We sometimes do have two or three repetitions of logic in the standard library; however, our needs tend to be much different from end-users. Also, we tend to benefit from the loose coupling and not turning every little detail into a published cross-module API. Now that we've propagated the as_integer_ratio() into bool, int, float, Decimal, and Fraction, I propose we stop there. This micro-problem to too small to warrant adding yet more machinery and API creep. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 16:28:31 2019 From: report at bugs.python.org (Abhilash Raj) Date: Mon, 19 Aug 2019 20:28:31 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1566246511.94.0.940796928086.issue34155@roundup.psfhosted.org> Abhilash Raj added the comment: 2.7 needs a separate PR since the code is very different and my familiarity with 2.7 version of email package is very limited. I am going to work on a separate patch later this week for 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 16:59:07 2019 From: report at bugs.python.org (Eryk Sun) Date: Mon, 19 Aug 2019 20:59:07 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566248347.4.0.643485456029.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: Here's the requested overview for the case where name-surrogate reparse points are handled as winlinks (Windows links), but S_IFLNK is reserved for IO_REPARSE_TAG_SYMLINK. I took the time this afternoon to write it up in C, which hopefully is clearer than my prose. It handles all CreateFileW failures inline, but uses a recursive call to traverse a non-link. No reparse tag values are hard coded in win32_xstat_impl. I extended it to support devices that aren't file systems, such as "con", disk volumes, and raw disks. This enhancement was requested on another issue, but it may as well get updated in this issue if win32_xstat_impl is getting overhauled. Some of these devices are already supported by fstat(). The latter can be extended similarly to support volume devices and raw disk devices. I opted to fail the call in the unhandled-tag case if it opens a link that should be traversed. Either it's an unhandled link, which is an unacceptable condition (i.e. it should be a sink, not a link), or it's a link or sequence of links to an unhandled reparse point. Returning the link reparse-point data is not what the caller wants from a successful stat(). --- static int win32_xstat_impl(const wchar_t *path, struct _Py_stat_struct *result, BOOL traverse) { HANDLE hFile; BY_HANDLE_FILE_INFORMATION fileInfo; FILE_ATTRIBUTE_TAG_INFO tagInfo = { 0 }; DWORD fileType, error; BOOL isUnhandledTag = FALSE; int retval = 0; DWORD access = FILE_READ_ATTRIBUTES; DWORD flags = FILE_FLAG_BACKUP_SEMANTICS; /* Allow opening directories. */ if (!traverse) { flags |= FILE_FLAG_OPEN_REPARSE_POINT; } hFile = CreateFileW(path, access, 0, NULL, OPEN_EXISTING, flags, NULL); if (hFile == INVALID_HANDLE_VALUE) { /* Either the path doesn't exist, or the caller lacks access. */ error = GetLastError(); switch (error) { case ERROR_ACCESS_DENIED: /* Cannot sync or read attributes. */ case ERROR_SHARING_VIOLATION: /* It's a paging file. */ /* Try reading the parent directory. */ if (!attributes_from_dir(path, &fileInfo, &tagInfo.ReparseTag)) { /* Cannot read the parent directory. */ SetLastError(error); return -1; } if (fileInfo.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) { if (traverse || !IsReparseTagNameSurrogate(tagInfo.ReparseTag)) { /* The stat call has to traverse but cannot, so fail. */ SetLastError(error); return -1; } } break; case ERROR_INVALID_PARAMETER: /* \\.\con requires read or write access. */ hFile = CreateFileW(path, access | GENERIC_READ, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, flags, NULL); if (hFile == INVALID_HANDLE_VALUE) { SetLastError(error); return -1; } break; case ERROR_CANT_ACCESS_FILE: /* bpo37834: open unhandled reparse points if traverse fails. */ if (traverse) { traverse = FALSE; isUnhandledTag = TRUE; hFile = CreateFileW(path, access, 0, NULL, OPEN_EXISTING, flags | FILE_FLAG_OPEN_REPARSE_POINT, NULL); } if (hFile == INVALID_HANDLE_VALUE) { SetLastError(error); return -1; } break; default: return -1; } } if (hFile != INVALID_HANDLE_VALUE) { /* Query the reparse tag, and traverse a non-link. */ if (!traverse) { if (!GetFileInformationByHandleEx(hFile, FileAttributeTagInfo, &tagInfo, sizeof(tagInfo))) { /* Allow devices that do no support FileAttributeTagInfo. */ error = GetLastError() ; if (error == ERROR_INVALID_PARAMETER || error == ERROR_INVALID_FUNCTION || error == ERROR_NOT_SUPPORTED) { tagInfo.FileAttributes = FILE_ATTRIBUTE_NORMAL; tagInfo.ReparseTag = 0; } else { retval = -1; goto cleanup; } } else if (tagInfo.FileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) { if (IsReparseTagNameSurrogate(tagInfo.ReparseTag)) { if (isUnhandledTag) { /* Traversing previously failed for either this link or its target. */ SetLastError(ERROR_CANT_ACCESS_FILE); retval = -1; goto cleanup; } /* Traverse a non-link, but not if traversing already failed for an unhandled tag. */ } else if (!isUnhandledTag) { CloseHandle(hFile); return win32_xstat_impl(path, result, TRUE); } } } fileType = GetFileType(hFile); if (fileType != FILE_TYPE_DISK) { if (fileType == FILE_TYPE_UNKNOWN && GetLastError() != 0) { retval = -1; goto cleanup; } DWORD fileAttributes = GetFileAttributesW(path); memset(result, 0, sizeof(*result)); if (fileAttributes != INVALID_FILE_ATTRIBUTES && fileAttributes & FILE_ATTRIBUTE_DIRECTORY) { /* \\.\pipe\ or \\.\mailslot\ */ result->st_mode = _S_IFDIR; } else if (fileType == FILE_TYPE_CHAR) { /* \\.\nul */ result->st_mode = _S_IFCHR; } else if (fileType == FILE_TYPE_PIPE) { /* \\.\pipe\spam */ result->st_mode = _S_IFIFO; } /* FILE_TYPE_UNKNOWN, e.g. \\.\mailslot\waitfor.exe\spam */ goto cleanup; } if (!GetFileInformationByHandle(hFile, &fileInfo)) { error = GetLastError(); if (error != ERROR_INVALID_PARAMETER && error != ERROR_INVALID_FUNCTION && error != ERROR_NOT_SUPPORTED) { retval = -1; goto cleanup; } /* Volumes and physical disks are block devices, e.g. \\.\C: and \\.\PhysicalDrive0. */ memset(result, 0, sizeof(*result)); result->st_mode = 0x6000; /* S_IFBLK */ goto cleanup; } } _Py_attribute_data_to_stat(&fileInfo, tagInfo.ReparseTag, result); if (!(fileInfo.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)) { /* Fix the file execute permissions. This hack sets S_IEXEC if the filename has an extension that is commonly used by files that CreateProcessW can execute. A real implementation calls GetSecurityInfo, OpenThreadToken/OpenProcessToken, and AccessCheck to check for generic read, write, and execute access. */ const wchar_t *fileExtension = wcsrchr(path, '.'); if (fileExtension) { if (_wcsicmp(fileExtension, L".exe") == 0 || _wcsicmp(fileExtension, L".bat") == 0 || _wcsicmp(fileExtension, L".cmd") == 0 || _wcsicmp(fileExtension, L".com") == 0) { result->st_mode |= 0111; } } } cleanup: if (hFile != INVALID_HANDLE_VALUE) { CloseHandle(hFile); } return retval; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 17:20:15 2019 From: report at bugs.python.org (Eryk Sun) Date: Mon, 19 Aug 2019 21:20:15 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566249615.56.0.734355637631.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: Here are two additional differences between mount points and symlinks: (1) A mount point in a remote path is always evaluated on the server and restricted to devices that are local to the server. So if we handle a mount point as if it's a POSIX symlink that works with readlink(), then what are we to do with the server's drive "Z:"? Genuine symlinks are evaluated on the client, so readlink() always makes sense. (Though if we resolve a symlink manually, then we're bypassing the system's R2L symlink policy.) (2) A mount point has its own security that's checked in addition to the security on the target directory when it's reparsed. In contrast, security set on a symlink is not checked when the link is reparsed, which is why icacls.exe implicitly resolves a symlink when setting and viewing security unless the /L option is used. > - if it's a directory junction, call os.stat instead and return that > (???) I wanted lstat in Windows to traverse mount points by default (but I gave up on this), as it does in Unix, because a mount point behaves like a hard name grafting in a path. This is important for relative symlinks that use ".." components to traverse above their parent directory. The result is different from a directory symlink that targets the same path. A counter-argument (in favor of winlinks) is that a mount point is still ultimately a name-surrogate reparse point, so, unlike a hard link, its existence doesn't prevent the directory from being deleted. It's left in place as a dangling link if the target is deleted or the device is removed from the system. Trying to follow it fails with ERROR_PATH_NOT_FOUND or ERROR_FILE_NOT_FOUND. Also, handling a mount point as a directory by default would require an additional parameter because in some cases we need to be able to open a junction instead of traversing it, such as to implement shutil.rmtree to behave like CMD's `rmdir /s`. Another place identifying a mount point is required, unfortunately, is in realpath(). Ideally we would be able to handle mount points as just directories. The problem is that NT allows a mount point to target a symlink, something that's not allowed in Unix. Traversing the mount point is effectively the same as traversing the symlink. So we have to read the mount-point target, and if it's a symlink, we have to read and evaluate it. (Consequently it seems that getting the real path for a remote path is an intractable problem when mount points are involved. We can only get the final path.) --- Even without the addition of a new parameter, we may still want to limit the definition of 'link' in Windows lstat to name-surrogate reparse points, i.e. winlinks. Reparse points that aren't name surrogates don't behave like links. They behave like the file itself, and reparsing may automatically replace the reparse point with the real file. Some of them are even directories that have the directory bit (28) set in the tag value, which means they're allowed to contain other files. (Without the directory tag bit, setting a reparse point on a non-empty directory should fail.) The counter-argument to changing lstat to only open winlinks is that changing the meaning of 'link' in lstat is too disruptive to existing software that may depend on the old behavior, i.e. opening any reparse point. I think the use cases for opening non-links are rare enough that it's not beyond the pale to change this behavior in 3.8 or 3.9. > Right, but is that because they deliberately want the junction > to be treated like a file? Or because they want it to be treated > like the directory is really right there? For copytree it makes sense to traverse a mount point as a directory. We can't reliably copy a mount point. In Unix, even when a volume mount or bind mount can be detected, there's no standard way to clone it to a new mount point, and even if there were, that would require super-user access. In Windows, we could wrap CreateDirectorExW, which can copy a mount point, but it requires administrator access to copy a volume mount point (i.e. "\\\\?\\Volume{...}\\"), for which it calls SetVolumeMountPointW in order to update the mount-point manager in the kernel. We also have a limited ability to create mount points via _winapi.CreateJunction, but it's buggy in corner cases and incomplete. It suffices for the reason it was added -- testing the ability to delete a junction via os.remove(). > os.rmdir() already does special things to behave like a junction > rather than the real directory, This is similar in spirit to Unix, except Unix refuses to delete a mount point. For example, if we have a Unix bind mount to a non-empty directory, rmdir() fails with EBUSY. On the other hand, rmdir() on the real directory fails with ENOTEMPTY. If Unix handled the mount point as if it's just the mounted directory, I'd expect the error to be the same. It's not particularly special in Windows unless it's a volume mount point. Then RemoveDirectoryW tries to call DeleteVolumeMountPointW. This could be a case where it would fail to remove a mount point, just like Unix. But the internal DeleteVolumeMountPointW call is allowed to fail if the caller doesn't have access to update the mount-point manager, in which case it removes the junction anyway. The consequence of failing to update the mount-point manager is that GetFinalPathNameByHandleW calls will subsequently return a non-existing path for a volume that was mounted only in the deleted folder (i.e. the volume isn't also assigned a drive letter). Thus we can't assume the result from GetFinalPathNameByHandleW exists. This just pertains to volume mount points, which are special to the mount-point manager because it uses them to translate a native device path into a canonical DOS path. Bind mount points have no special significance to the mount-point manager. > the islink/readlink/symlink process is going to be problematic on > Windows since most users can't create symlinks. Then copying the symlink fails, which I think is better than silently transforming the behavior from a mount point to a symlink. Defensive code can fall back on physically copying the target file or directory. The latter is the default behavior for copytree. It's only an issue if code calls copytree(src, dst, symlinks=True). However, it's always a concern with shutil.move(), which attempts to move a file via os.rename. This fails for a cross-volume rename. Then if islink() is true, it falls back on os.symlink(os.readlink(src), real_dst) and os.unlink(src). (On my own systems, I grant the symlink privilege to the Authenticated Users group, which allows symlink creation by standard users and administrators -- elevated or not. But in general, a fear of symlinks is warranted, even in Unix.) > I'm proposing to fix the inconsistency by fixing the flags. Your > proposal is to fix the inconsistency by generating a new error in > unlink()? (Just clarifying.) unlink() didn't used to remove junctions prior to 3.5 (see issue 18314). Instead of rolling back the change, or conflating the meaning of S_IFLNK, a counter-proposal is to harmonize unlink with the proposed change to lstat, i.e. to allow removing all name-surrogate directories. A name-surrogate directory cannot have children in the directory itself, so allowing it for os.unlink is in the spirit of the function, even if doing so is inconsistent with the literal specification. This is documented in ntifs.h: D [bit 28] is the directory bit. When set to 1, indicates that any directory with this reparse tag can have children. Has no special meaning when used on a non-directory file. Not compatible with the name surrogate bit [bit 29]. Regarding the directory bit, the registered tags with this bit are IO_REPARSE_TAG_CLOUD*, IO_REPARSE_TAG_WCI_1, and IO_REPARSE_TAG_PROJFS (for projected file systems). > Currently Windows shutil.rmtree traverses into junctions and deletes > everything, though it then succeeds to delete the junction. That's like Unix mount-point behavior, except Windows allows a volume mount point to be deleted (not just a bind mount point), despite negative consequences to API functions such as GetFinalPathNameByHandleW if the user isn't allowed to update the system database of volume mount points. An issue here, and with all code that walks a tree (especially destructively), is the link behavior of mount points. Bind mount points have the same problem in both Unix and Windows. For example, shutil.rmtree will fail to remove a mount point that targets a directory that it already removed. It's a different OSError in Unix vs Windows (EBUSY vs ENOENT or ERROR_PATH_NOT_FOUND), but an error all the same. That in itself is not an argument to handle a junction as a symlink, because it's still a mount point that behaves as such, even if someone is using it as a symlink. However, it is an argument for special handling of winlinks, which would allow the Windows implementation to behave better than Unix, IMO, in addition to helping Windows users that are forced to use mount points instead of symlinks. > With my change, rmtree() directly on a junction now raises (could be > fixed?) but rmtree on a directory containing a junction will remove > the junction without touching the target directory. So I think we're > both happy about this one. Changing rmtree to work on a target directory that claims to be a symlink would require special casing Windows in shutil.rmtree. But in general this is a problem that affects all code that looks for symlinks, not just code in the standard library. If the meaning of S_IFLNK remains the same, then existing code has the option of being upgraded to delete directory winlinks without traversing them, but nothing is forced on them. In this case, for example, we could wrap the os.scandir call: if not _WINDOWS: _rmtree_unsafe_scandir = os.scandir else: import contextlib def _rmtree_unsafe_scandir(path): try: st = os.lstat(path) attr, tag = st.st_file_attributes, st.st_reparse_tag except OSError: attr = tag = 0 if (attr & stat.FILE_ATTRIBUTE_DIRECTORY and attr & stat.FILE_ATTRIBUTE_REPARSE_POINT and tag & 0x2000_0000): # IsReparseTagNameSurrogate return contextlib.nullcontext([]) else: return os.scandir(path) For a directory winlink, the above _rmtree_unsafe_scandir function returns a context manager that yields an empty list, so _rmtree_unsafe skips to os.rmdir(path). This reproduces the behavior of CMD's `rmdir /s`, which will not traverse any name-surrogate reparse point (it checks the tag for the name-surrogate bit) even if the reparse point is the target directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 17:40:35 2019 From: report at bugs.python.org (Roger Gammans) Date: Mon, 19 Aug 2019 21:40:35 +0000 Subject: [issue36723] Unittest Discovery for namespace subpackages dot notation fails In-Reply-To: <1556219043.29.0.793780129066.issue36723@roundup.psfhosted.org> Message-ID: <1566250835.54.0.906033310031.issue36723@roundup.psfhosted.org> Roger Gammans added the comment: I?think this is a duplicate of one (or both) of 35617, or 23882 . Both of those have unmerged proposed fixes. ---------- nosy: +rgammans _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 17:42:26 2019 From: report at bugs.python.org (Roger Gammans) Date: Mon, 19 Aug 2019 21:42:26 +0000 Subject: [issue35617] unittest discover does not work with implicit namespaces In-Reply-To: <1546162337.0.0.646769357962.issue35617@roundup.psfhosted.org> Message-ID: <1566250946.92.0.877008674358.issue35617@roundup.psfhosted.org> Change by Roger Gammans : ---------- nosy: +rgammans _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 17:43:04 2019 From: report at bugs.python.org (Roger Gammans) Date: Mon, 19 Aug 2019 21:43:04 +0000 Subject: [issue23882] unittest discovery doesn't detect namespace packages when given no parameters In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1566250984.15.0.0639772674604.issue23882@roundup.psfhosted.org> Change by Roger Gammans : ---------- nosy: +rgammans _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 18:25:33 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 19 Aug 2019 22:25:33 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566253533.81.0.333386790125.issue37834@roundup.psfhosted.org> Steve Dower added the comment: Thanks for the code snippet, that helped me a lot (and since you went to the trouble of fixing other bugs, I guess I'll have to merge it into my PR now). Any particular reason you did GetFileAttributesW(path) in the non-FILE_TYPE_DISK case when we have the hFile around? I'm trying to get one more opinion from a colleague on setting S_IFLNK for all name surrogate reparse points vs. only symlinks by default (the Python/fileutils.c change, and implicitly the fixes to Lib/shutil.py). I might try and get some broader opinions as well on whether "is_dir() is true, do you suspect it could be a junction" vs "is_link() is true, do you suspect it could be a junction", since that is what it really comes down to. (We need to make changes to shutil to match Explorer anyway - rmtree should not recurse, and copytree should.) However, the minimal change is to leave S_IFLNK only for symlinks, so unless I get a strong case for treating all name surrogates as links, I'll revert to that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 18:37:20 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 22:37:20 +0000 Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org> Message-ID: <1566254240.54.0.606662787448.issue37788@roundup.psfhosted.org> STINNER Victor added the comment: New changeset d3dcc92778807ae8f7ebe85178f36a29711cd478 by Victor Stinner in branch 'master': bpo-37788: Fix a reference leak if a thread is not joined (GH-15228) https://github.com/python/cpython/commit/d3dcc92778807ae8f7ebe85178f36a29711cd478 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 18:37:31 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 19 Aug 2019 22:37:31 +0000 Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org> Message-ID: <1566254251.1.0.148767056187.issue37788@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15053 pull_request: https://github.com/python/cpython/pull/15336 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 18:37:45 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 19 Aug 2019 22:37:45 +0000 Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org> Message-ID: <1566254265.3.0.569331650315.issue37788@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15054 pull_request: https://github.com/python/cpython/pull/15337 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 19:16:33 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 19 Aug 2019 23:16:33 +0000 Subject: [issue37889] "Fatal Python error: Py_EndInterpreter: not the last thread" that's bad Message-ID: <1566256593.58.0.888116360653.issue37889@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : The x86-64 High Sierra 3.x buildbot and AMD64 FreeBSD CURRENT Shared 3.x are failing with: Fatal Python error: Py_EndInterpreter: not the last thread https://buildbot.python.org/all/#/builders/145/builds/2233 https://buildbot.python.org/all/#/builders/168/builds/1295 Fatal Python error: Py_EndInterpreter: not the last thread Current thread 0x00007fff8e587380 (most recent call first): File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/support/__init__.py", line 2911 in run_in_subinterp File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/test_threading.py", line 1006 in test_threads_join_2 File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/unittest/case.py", line 611 in _callTestMethod File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/unittest/case.py", line 654 in run File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/unittest/case.py", line 714 in __call__ File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__ File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__ File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__ File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/unittest/runner.py", line 176 in run File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/support/__init__.py", line 1996 in _run_suite File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/support/__init__.py", line 2092 in run_unittest File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 209 in _test_module File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 234 in _runtest_inner2 File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 153 in _runtest File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 193 in runtest File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 310 in rerun_failed_tests File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 678 in _main File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 628 in main File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 695 in main File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/__main__.py", line 2 in File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/runpy.py", line 85 in _run_code File "/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/runpy.py", line 192 in _run_module_as_main make: *** [buildbottest] Abort trap: 6 program finished with exit code 2 elapsedTime=1799.062811 test_threads_join_2 (test.test_threading.SubinterpThreadingTests) ... https://buildbot.python.org/all/#/builders/145/builds/2233 ---------- messages: 349974 nosy: pablogsal, vstinner priority: normal severity: normal status: open title: "Fatal Python error: Py_EndInterpreter: not the last thread" that's bad versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 19:18:23 2019 From: report at bugs.python.org (Eryk Sun) Date: Mon, 19 Aug 2019 23:18:23 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566256703.11.0.331760959325.issue37834@roundup.psfhosted.org> Eryk Sun added the comment: > Any particular reason you did GetFileAttributesW(path) in the > non-FILE_TYPE_DISK case when we have the hFile around? The point of getting the file attributes is to identify the root directory of the namedpipe and mailslot file systems. For example, os.listdir('//./pipe') works because we append "\\*.*" to the path. GetFileInformationByHandle[Ex] forbids a pipe handle, for reasons that may no longer be relevant in Windows 10 (?). I remembered the restriction in the above case, but it seems I forgot about it when querying the tag. So the order of the GetFileInformationByHandleEx and GetFileType blocks actually needs to be flipped. That would be a net improvement anyway since there's no point in querying a reparse tag from a device that's not a file system (namedpipe and mailslot are 'file systems', but only at the most basic level). I can't imagine there being a problem with querying FileBasicInfo to get the file attributes. I just checked that it works fine with "//./pipe/" and "//./mailslot/" -- at least in Windows 10. Anyway, GetFileAttributesW uses a query-only open that doesn't create a real file object or even require an IRP usually, so it's not adding much cost compared to querying FileBasicInfo using the handle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 19:22:38 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 19 Aug 2019 23:22:38 +0000 Subject: [issue37889] "Fatal Python error: Py_EndInterpreter: not the last thread" that's bad In-Reply-To: <1566256593.58.0.888116360653.issue37889@roundup.psfhosted.org> Message-ID: <1566256958.62.0.260092300068.issue37889@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: See also https://bugs.python.org/issue37788 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 19:23:18 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 19 Aug 2019 23:23:18 +0000 Subject: [issue37889] Fatal Python error: Py_EndInterpreter: not the last thread In-Reply-To: <1566256593.58.0.888116360653.issue37889@roundup.psfhosted.org> Message-ID: <1566256998.73.0.384001046396.issue37889@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- title: "Fatal Python error: Py_EndInterpreter: not the last thread" that's bad -> Fatal Python error: Py_EndInterpreter: not the last thread _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 19:28:01 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 23:28:01 +0000 Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org> Message-ID: <1566257281.01.0.75663377157.issue37788@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15055 pull_request: https://github.com/python/cpython/pull/15338 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 19:29:05 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 23:29:05 +0000 Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org> Message-ID: <1566257345.93.0.65360208427.issue37788@roundup.psfhosted.org> STINNER Victor added the comment: > https://github.com/python/cpython/commit/d3dcc92778807ae8f7ebe85178f36a29711cd478 This change introduced a regression :-( https://github.com/python/cpython/pull/15228#issuecomment-522792133 I created PR 15338 to revert it ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 19:30:53 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 23:30:53 +0000 Subject: [issue37889] Fatal Python error: Py_EndInterpreter: not the last thread In-Reply-To: <1566256593.58.0.888116360653.issue37889@roundup.psfhosted.org> Message-ID: <1566257453.43.0.624961138621.issue37889@roundup.psfhosted.org> STINNER Victor added the comment: It's a regression caused by bpo-37788. I created PR 15338 to revert my change. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> fix for bpo-36402 (threading._shutdown() race condition) causes reference leak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 19:33:17 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 23:33:17 +0000 Subject: [issue37878] Sub-Interpreters : Document PyThreadState_DeleteCurrent() In-Reply-To: <1565985235.6.0.212314052144.issue37878@roundup.psfhosted.org> Message-ID: <1566257597.3.0.527107633415.issue37878@roundup.psfhosted.org> STINNER Victor added the comment: Is it safe to call PyThreadState_DeleteCurrent()? ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 19:47:10 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 19 Aug 2019 23:47:10 +0000 Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition) causes reference leak In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org> Message-ID: <1566258430.92.0.743878391628.issue37788@roundup.psfhosted.org> STINNER Victor added the comment: New changeset d11c2c607768fa549b1aed7899edc061b2ebf19f by Victor Stinner in branch 'master': Revert "bpo-37788: Fix a reference leak if a thread is not joined (GH-15228)" (GH-15338) https://github.com/python/cpython/commit/d11c2c607768fa549b1aed7899edc061b2ebf19f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 19:48:03 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 19 Aug 2019 23:48:03 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566258483.01.0.745469421267.issue37834@roundup.psfhosted.org> Steve Dower added the comment: > So the order of the GetFileInformationByHandleEx and GetFileType blocks actually needs to be flipped. I've done that now. And thanks for confirming. That was my suspicion, but I wasn't sure if you knew something here that I didn't (v. likely!). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 20:11:48 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 20 Aug 2019 00:11:48 +0000 Subject: [issue37887] some leak in the compiler_assert function In-Reply-To: <1566226503.82.0.418800588376.issue37887@roundup.psfhosted.org> Message-ID: <1566259908.98.0.200166613288.issue37887@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Hi hai shi, As you can see in other pars of the code base objects returned from PyUnicode_InternFromString that have static storage class do not need to be deallocated in case there is a failure, so this is not considered a leak as there will be only one owned object across all calls. The Python object is reused every time the function is call (so in successive calls the object can be reused and therefore assertion_error!= NULL). ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 20:15:35 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 20 Aug 2019 00:15:35 +0000 Subject: [issue37883] threading.Lock.locked is not documented In-Reply-To: <1566153378.15.0.0440090654943.issue37883@roundup.psfhosted.org> Message-ID: <1566260135.26.0.351802785134.issue37883@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +newcomer friendly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 21:28:09 2019 From: report at bugs.python.org (Hua Liu) Date: Tue, 20 Aug 2019 01:28:09 +0000 Subject: [issue37866] PyModule_GetState Segmentation fault when called Py_Initialize In-Reply-To: <1565862147.92.0.832286772909.issue37866@roundup.psfhosted.org> Message-ID: <1566264489.22.0.332691211053.issue37866@roundup.psfhosted.org> Change by Hua Liu : ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 21:33:56 2019 From: report at bugs.python.org (Greg Price) Date: Tue, 20 Aug 2019 01:33:56 +0000 Subject: [issue36502] str.isspace() for U+00A0 and U+202F differs from document In-Reply-To: <1554186967.56.0.21483381742.issue36502@roundup.psfhosted.org> Message-ID: <1566264836.07.0.45444041395.issue36502@roundup.psfhosted.org> Greg Price added the comment: Thanks Victor for the reviews and merges! (Unmarking 2.7, because https://docs.python.org/2/library/stdtypes.html seems to not have this issue.) ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 22:48:16 2019 From: report at bugs.python.org (Kyle Stanley) Date: Tue, 20 Aug 2019 02:48:16 +0000 Subject: [issue37890] Modernize several tests in test_importlib Message-ID: <1566269296.72.0.828504709815.issue37890@roundup.psfhosted.org> New submission from Kyle Stanley : Last month, several tests were moved into test_importlib (https://bugs.python.org/issue19696): "test_pkg_import.py", "test_threaded_import.py", and "threaded_import_hangers.py". Those tests were created quite a while ago though and do not currently utilize importlib directly. They should be updated accordingly. Brett Cannon: > BTW, if you want to open a new issue and modernize the tests to use importlib directly that would be great! I'm interested in helping with this issue, but I may require some assistance as I'm not overly familiar with the internals of importlib. I'll probably start with "test_pkg_import.py". Anyone else can feel free to work on the other two in the meantime, but they should be worked on together as "threaded_import_hangers.py" is a dependency for "test_threaded_import.py". ---------- components: Tests messages: 349984 nosy: aeros167, brett.cannon priority: normal severity: normal status: open title: Modernize several tests in test_importlib versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 23:43:42 2019 From: report at bugs.python.org (Kyle Stanley) Date: Tue, 20 Aug 2019 03:43:42 +0000 Subject: [issue37890] Modernize several tests in test_importlib In-Reply-To: <1566269296.72.0.828504709815.issue37890@roundup.psfhosted.org> Message-ID: <1566272622.05.0.278937603321.issue37890@roundup.psfhosted.org> Kyle Stanley added the comment: I'm not entirely certain as to which parts should be modernized, and which ones can remain the same. A large part of my uncertainty is that there are no header comments for "test_pkg_import.py" to explain the test coverage, so I don't know if there are additional tests beyond the existing ones that should be added. The first steps I can think of: 1) Use ``importlib.import_module()`` instead of the built-in ``__import__()`` 2) Use ``with self.assertRaises(, ): ...`` instead of ``` try: __import__(self.module_name) except SyntaxError: pass else: raise RuntimeError('Failed to induce SyntaxError') # self.fail()? ... ``` 3) Replace ``self.assertEqual(getattr(module, var), 1)`` with ``self.assertEqual(getattr(module, var, None), 1)`` so that AttributeErrors are not raised when unexpected behaviors occur 4) Provide useful error messages for failed assertions I'll begin working on those, probably with a separate PR for each of them for ease of review. Let me know if there's anything else I should do, or if any of the above steps are unneeded. If I think of anything else I'll update the issue accordingly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 23:49:09 2019 From: report at bugs.python.org (Kyle Stanley) Date: Tue, 20 Aug 2019 03:49:09 +0000 Subject: [issue37890] Modernize several tests in test_importlib In-Reply-To: <1566269296.72.0.828504709815.issue37890@roundup.psfhosted.org> Message-ID: <1566272949.7.0.328972912164.issue37890@roundup.psfhosted.org> Change by Kyle Stanley : ---------- nosy: +eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 19 23:51:22 2019 From: report at bugs.python.org (Vinay Sharma) Date: Tue, 20 Aug 2019 03:51:22 +0000 Subject: [issue37754] Persistence of Shared Memory Segment after process exits In-Reply-To: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> Message-ID: <1566273082.24.0.154683797658.issue37754@roundup.psfhosted.org> Change by Vinay Sharma : ---------- title: alter size of segment using multiprocessing.shared_memory -> Persistence of Shared Memory Segment after process exits _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 00:03:51 2019 From: report at bugs.python.org (Netzeband) Date: Tue, 20 Aug 2019 04:03:51 +0000 Subject: [issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class In-Reply-To: <1565689003.91.0.0312877377737.issue37835@roundup.psfhosted.org> Message-ID: <1566273831.81.0.608453654406.issue37835@roundup.psfhosted.org> Netzeband added the comment: Thanks for your response. I was also thinking much about it and was not able to find a nice idea how to get this working. The problem is, that we loose the local-namespace information as soon as we leave the context of the function, where the class was defined in. This information is not stored in the function object of the method, we want to get the type hints from. The only open question, I have in this context is: Why can python resolve the reference to class A (also a inner class, but no forward declaration)? Is there any chance to use the same mechanism also for forward declared references? Beside from this question, I will give you my thoughts, how I think this issue could be addressed: - What we need is the local namespace information from the function, where the inner class was defined in. This is not stored from python in the function object of this class (but __global__ is stored). - Maybe any upcoming python version could store this information in __local__ ? So maybe we could clone this ticket to the python core in order to address this? - As long as python is not storing this information, a workaround could be used: We could define a function decorator, which adds the attribute __local__ to a function object. I think about this syntax: class InnerClass(): @store_namespace(locals()) def method() -> 'InnerClass': ... - The get_type_hints function is then checking for the __local__ attribute and if it exits it is passed to the function, which resolves the forward declaration. This workaround is not beautiful, since it requires manual work for those methods (adding the function decorator to those methods). Furthermore - without knowing the internals of the get_type_hints function - this workaround is not straight forward and easy to understand. So it needs to be carefully documented and even then I expect confusing questions on StackOverflow or other communities. However, it is a quite rare case that someone really needs to use inner classes. Normally one could simply put the class in the global namespace. But when this happens and there is really a need for it, than this workaround would make it possible. Furthermore, checking a __local__ attribute of the function object would be a nice preparation for a feature request to the python core, which should store the reference to the local namespace for every function object, without using any decorators. What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 00:11:18 2019 From: report at bugs.python.org (Vinay Sharma) Date: Tue, 20 Aug 2019 04:11:18 +0000 Subject: [issue37754] Persistence of Shared Memory Segment after process exits In-Reply-To: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> Message-ID: <1566274278.08.0.265787700889.issue37754@roundup.psfhosted.org> Vinay Sharma added the comment: Hi Davin, Thanks for replying! As you said I went through the issue, and now understand why segments should not be automatically created if they don't exist. But, after reading that thread I got to know that shared memory is supposed to exist even if the process exits, and it can only be freed by unlink, which I also believe is an important functionality required by many use cases as you mentioned. But, this is not the behaviour currently. As soon as the process exists, all the shared memory created is unlinked. Also, the documentation currently mentions: "shared memory blocks may outlive the original process that created them", which is not the case at all. Currently, the resource_tracker, unlinks the shared memory, by calling unlink as specified here: ``` if os.name == 'posix': import _multiprocessing import _posixshmem _CLEANUP_FUNCS.update({ 'semaphore': _multiprocessing.sem_unlink, 'shared_memory': _posixshmem.shm_unlink, }) ``` So, is this an expected behaviour, if yes documentation should be updated, and if not the code base should be. I will be happy to submit a patch in both the cases. PS: I personally believe from my experience that shared memory segments should outlive the process, unless specified otherwise. Also, a argument persist=True, can be added which can ensure that the shared_memory segment outlives the process, and can be used by processes which are spawned later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 00:31:00 2019 From: report at bugs.python.org (Netzeband) Date: Tue, 20 Aug 2019 04:31:00 +0000 Subject: [issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class In-Reply-To: <1565689003.91.0.0312877377737.issue37835@roundup.psfhosted.org> Message-ID: <1566275460.53.0.551937905821.issue37835@roundup.psfhosted.org> Netzeband added the comment: I tried my idea with the small example code above. However it does not work like expected: (see zipped example project, attached to this comment) At the moment where the function decorator is applied to the method of the inner class, the local namespace ("locals()") does not contain any inner class. Even not another inner class, define before the corresponding class. So the only way to get it working is to add the __locals__ attribute manually after defining the class, which is even more ugly than my suggested workaround with the function decorator :-( Any further ideas about this? ---------- Added file: https://bugs.python.org/file48552/get_type_hints_for_inner_classes.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 01:04:25 2019 From: report at bugs.python.org (Kyle Stanley) Date: Tue, 20 Aug 2019 05:04:25 +0000 Subject: [issue37890] Modernize several tests in test_importlib In-Reply-To: <1566269296.72.0.828504709815.issue37890@roundup.psfhosted.org> Message-ID: <1566277465.03.0.812238066896.issue37890@roundup.psfhosted.org> Change by Kyle Stanley : ---------- stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 01:40:31 2019 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 20 Aug 2019 05:40:31 +0000 Subject: [issue37868] `is_dataclass` returns `True` if `getattr` always succeeds. In-Reply-To: <1565870535.54.0.93577990924.issue37868@roundup.psfhosted.org> Message-ID: <1566279631.89.0.472939970885.issue37868@roundup.psfhosted.org> Eric V. Smith added the comment: New changeset b0f4dab8735f692bcfedcf0fa9a25e238a554bab by Eric V. Smith in branch 'master': bpo-37868: Improve is_dataclass for instances. (GH-15325) https://github.com/python/cpython/commit/b0f4dab8735f692bcfedcf0fa9a25e238a554bab ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 01:40:39 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 20 Aug 2019 05:40:39 +0000 Subject: [issue37868] `is_dataclass` returns `True` if `getattr` always succeeds. In-Reply-To: <1565870535.54.0.93577990924.issue37868@roundup.psfhosted.org> Message-ID: <1566279639.57.0.108856208088.issue37868@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15056 pull_request: https://github.com/python/cpython/pull/15339 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 01:40:46 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 20 Aug 2019 05:40:46 +0000 Subject: [issue37868] `is_dataclass` returns `True` if `getattr` always succeeds. In-Reply-To: <1565870535.54.0.93577990924.issue37868@roundup.psfhosted.org> Message-ID: <1566279646.0.0.352360669921.issue37868@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15057 pull_request: https://github.com/python/cpython/pull/15340 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 01:59:30 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 20 Aug 2019 05:59:30 +0000 Subject: [issue37868] `is_dataclass` returns `True` if `getattr` always succeeds. In-Reply-To: <1565870535.54.0.93577990924.issue37868@roundup.psfhosted.org> Message-ID: <1566280770.32.0.336408522781.issue37868@roundup.psfhosted.org> miss-islington added the comment: New changeset 1271ee8187df31debda7c556882a51ec356ca534 by Miss Islington (bot) in branch '3.8': bpo-37868: Improve is_dataclass for instances. (GH-15325) https://github.com/python/cpython/commit/1271ee8187df31debda7c556882a51ec356ca534 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 02:01:59 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 20 Aug 2019 06:01:59 +0000 Subject: [issue37868] `is_dataclass` returns `True` if `getattr` always succeeds. In-Reply-To: <1565870535.54.0.93577990924.issue37868@roundup.psfhosted.org> Message-ID: <1566280919.69.0.833903593423.issue37868@roundup.psfhosted.org> miss-islington added the comment: New changeset 02c1457a036c2af3e91beb952afdb66d9c806435 by Miss Islington (bot) in branch '3.7': bpo-37868: Improve is_dataclass for instances. (GH-15325) https://github.com/python/cpython/commit/02c1457a036c2af3e91beb952afdb66d9c806435 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 02:05:07 2019 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 20 Aug 2019 06:05:07 +0000 Subject: [issue37868] `is_dataclass` returns `True` if `getattr` always succeeds. In-Reply-To: <1565870535.54.0.93577990924.issue37868@roundup.psfhosted.org> Message-ID: <1566281107.99.0.522082801931.issue37868@roundup.psfhosted.org> Change by Eric V. Smith : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 02:41:53 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 20 Aug 2019 06:41:53 +0000 Subject: [issue37887] some leak in the compiler_assert function In-Reply-To: <1566226503.82.0.418800588376.issue37887@roundup.psfhosted.org> Message-ID: <1566283313.36.0.981532220109.issue37887@roundup.psfhosted.org> Serhiy Storchaka added the comment: Thank you for your patch hai shi. But note that assertion_error is a static variable. It is initialized only once. Your change makes it holding a borrowed reference after first call of compiler_assert(). This does not look reliable. In any case assertion_error will gone after resolving issue34880, so I am closing this issue in favor of that. If not issue34880, it would be better to use a private API for _Py_IDENTIFIER here. ---------- nosy: +serhiy.storchaka resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 03:02:11 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 20 Aug 2019 07:02:11 +0000 Subject: [issue37890] Modernize several tests in test_importlib In-Reply-To: <1566269296.72.0.828504709815.issue37890@roundup.psfhosted.org> Message-ID: <1566284531.82.0.925162408113.issue37890@roundup.psfhosted.org> Serhiy Storchaka added the comment: 1) __import__() can be used for purpose. I would not change this. 3) How would you distinguish the case when the module have an attribute with the value is None and when it does not have the attribute at all? This information would lost with your change. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 03:21:07 2019 From: report at bugs.python.org (Niels Albers) Date: Tue, 20 Aug 2019 07:21:07 +0000 Subject: [issue37891] Exceptions tutorial page does not mention raise from Message-ID: <1566285667.91.0.992762773609.issue37891@roundup.psfhosted.org> New submission from Niels Albers : raise from has been in the language since python 3, yet the tutorial page teaching about exceptions does not mention it. (see https://docs.python.org/3.7/tutorial/errors.html#raising-exceptions) It would be especially helpful to language newcomers to touch on the possibility of passing error context when raising a new exception in an exception handler. ---------- assignee: docs at python components: Documentation messages: 349994 nosy: Niels Albers, docs at python priority: normal severity: normal status: open title: Exceptions tutorial page does not mention raise from versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 03:22:12 2019 From: report at bugs.python.org (Niels Albers) Date: Tue, 20 Aug 2019 07:22:12 +0000 Subject: [issue37891] Exceptions tutorial page does not mention raise from In-Reply-To: <1566285667.91.0.992762773609.issue37891@roundup.psfhosted.org> Message-ID: <1566285732.59.0.641174235667.issue37891@roundup.psfhosted.org> Change by Niels Albers : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 04:43:27 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Tue, 20 Aug 2019 08:43:27 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566290607.64.0.498979072335.issue37884@roundup.psfhosted.org> Jeroen Demeyer added the comment: > AFAICT, no end-user has ever requested this ever. What do you mean with "this"? (A) A public function like math.as_integer_ratio() (B) Using as_integer_ratio() in the fractions.Fraction() constructor (C) The optimization of the fractions.Fraction() constructor For SageMath, (B) would be very useful. See https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/24?u=jdemeyer (replace __ratio__ by as_integer_ratio) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 05:03:53 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Tue, 20 Aug 2019 09:03:53 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566291833.75.0.189244169981.issue37884@roundup.psfhosted.org> Jeroen Demeyer added the comment: > our needs tend to be much different from end-users This issue is about fractions and statistics, which are closer to typical user libraries than CPython libraries. In fact, both could easily be packages on PyPI instead of part of the standard library. > no end-user has ever requested this ever. If math.as_integer_ratio() existed, probably SageMath would use it. On the other hand, the code for math.as_integer_ratio() is simple enough that SageMath could easily implement it if needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 05:08:20 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 20 Aug 2019 09:08:20 +0000 Subject: [issue37882] Code folding in IDLE In-Reply-To: <1566150411.87.0.37054908058.issue37882@roundup.psfhosted.org> Message-ID: <1566292100.43.0.815813480361.issue37882@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 06:24:12 2019 From: report at bugs.python.org (Printer Setup) Date: Tue, 20 Aug 2019 10:24:12 +0000 Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error 0x80070643: Failed to install MSI package. In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za> Message-ID: <1566296652.78.0.0531435230864.issue32545@roundup.psfhosted.org> Printer Setup added the comment: Fix Canon Printer Offline Windows 10 issues by following simple steps. Feel free to reach techies at Canon Support to resolve Canon Printer Offline issues. For more info: https://printeroffline.co/canon-printer/ ---------- nosy: +Printer Setup _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 06:38:15 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 20 Aug 2019 10:38:15 +0000 Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error 0x80070643: Failed to install MSI package. In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za> Message-ID: <1566297495.0.0.958983609124.issue32545@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- Removed message: https://bugs.python.org/msg349997 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 07:20:05 2019 From: report at bugs.python.org (Zackery Spytz) Date: Tue, 20 Aug 2019 11:20:05 +0000 Subject: [issue32793] smtplib: duplicated debug message In-Reply-To: <1518080718.92.0.467229070634.issue32793@psf.upfronthosting.co.za> Message-ID: <1566300005.25.0.225124077862.issue32793@roundup.psfhosted.org> Change by Zackery Spytz : ---------- pull_requests: +15058 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15341 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 07:22:16 2019 From: report at bugs.python.org (Zackery Spytz) Date: Tue, 20 Aug 2019 11:22:16 +0000 Subject: [issue32793] smtplib: duplicated debug message In-Reply-To: <1518080718.92.0.467229070634.issue32793@psf.upfronthosting.co.za> Message-ID: <1566300136.62.0.150193214405.issue32793@roundup.psfhosted.org> Change by Zackery Spytz : ---------- nosy: +ZackerySpytz type: -> behavior versions: +Python 3.9 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 07:28:09 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 11:28:09 +0000 Subject: [issue37732] Possible uninitialized variable in Objects/obmalloc.c In-Reply-To: <1564582636.59.0.312005293129.issue37732@roundup.psfhosted.org> Message-ID: <1566300489.15.0.512925898223.issue37732@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 18f8dcfa10d8a858b152d12a9ad8fa83b7e967f0 by Victor Stinner in branch 'master': bpo-37732: Fix GCC warning in _PyObject_Malloc() (GH-15333) https://github.com/python/cpython/commit/18f8dcfa10d8a858b152d12a9ad8fa83b7e967f0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 07:34:26 2019 From: report at bugs.python.org (hai shi) Date: Tue, 20 Aug 2019 11:34:26 +0000 Subject: [issue37887] some leak in the compiler_assert function In-Reply-To: <1566226503.82.0.418800588376.issue37887@roundup.psfhosted.org> Message-ID: <1566300866.8.0.575740157122.issue37887@roundup.psfhosted.org> hai shi added the comment: Ok, got it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 07:38:43 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 20 Aug 2019 11:38:43 +0000 Subject: [issue37892] IDLE Shell: isolate user code input Message-ID: <1566301123.94.0.491748175182.issue37892@roundup.psfhosted.org> New submission from Terry J. Reedy : The main operational difference between the standard Python REPL and IDLE's Shell is that the latter operates with complete Python statements rather than physical lines. Shell keeps the '>>>' prompt, but with the expanded meaning of "Enter a complete Python statement" rather than just "Enter the first line of a Python statement". It omits the consequently superfluous continuation prompts, which would mostly be a nuisance if left. Currently, the prompt precedes and indents the first line of code. This causes multiple problems. Internally, first lines have to be treated differently from the rest. This has lead to bugs, mostly but not all fixed. Externally, indentation depends on the prompt and does not look right or work right, compared to the same code in a proper editor. And it lead to the use of Tab for indents. The use of Tab for Shell indents was recognized as a problem by 2005. #1196946 proposed using the same space indents as in the editor, resulting, for instance, in >>> if a: if b: print(a+b) KBK rejected this with "Doesn't really solve the problem." In 2010, #7676 suggested 4 space indents again and added 2 variations: 8 space indents, and 8 followed by 4, etc. OP Cherniavsky Beni noted that Tab indents are "inconsistent with PEP 8; what's worse, it's makes copy-paste code between the shell and editor windows confusing and dangerous!" Raymond Hettinger later added that tabs are a "major PITA" and "a continual source of frustration for students". Starting with msg151418 in 1212, my response was much the same as KBK's. To me, the underlying problem is having the prompt physically indent the first physical line relative to the following lines. I consider this IDLE's single biggest design wart. I proposed then 3 possible solutions to avoid the first line non-significant indent. They are, with current comments, ... 1. Prompt on a line by itself (vertical separation). This is easy, and allows for an expanded active prompt, such as >>> Enter a complete Python statement on the lines below. This says exactly what the user should do and should help avoid confusion with a command-line prompt. ("I entered 'cd path' and got 'SyntaxError'".) Once a statement is entered, the instruction is obsolete. Only '>>>' is needed, to identify input from output. I think putting '>>>' above past input works less well than for current input. I will come back to this proposal below, after 3. 2. No input prompt; instead mark output (with #, for instance). Possible, but confronting beginners with no prompt would likely leave them wondering what to do. But this is a possible savefile format, one that could be run or edited. (A savefile with only the code would do the same.) 3. Prompt in a margin, as with line numbers (horizontal separation). In 1214, I realized that the 'margin' should be implemented as a separate sidebar widget, which was initially being developed for editor line numbers. We now have that, and a shell sidebar should be fairly easy. I will open a separate issue with a fairly specific design. Basically, the first lines of input, stderr output, and stdout output would be flagged with, for instance, '>>>', 'err', and 'out'. This should be done before the additional proposal below. IDLE's Shell should isolate user input not only from prompts. Debug on/off messages, warnings, and delayed program output can also interfere. I think that IDLE's Shell should consist of an input and output history area with sidebar, fixed prompt and separator line such as in 1. above, and active input area. The history area, as now, would be read-only except when responding to input() in the running code. The change is that it would receive all messages from IDLE and asynchronous program output. The input area would be a specialized editor area. When input code is run, it would be copied above the separator prompt with '>>>' added to the sidebar, opposite the first line. I believe that the easiest implementation would be to use a label for the fixed prompt line and a specialized editor that runs statements as entered. The editing and smart indents would be the same as in a regular editor. Once this is done, we could discuss refinements such as allowing pasting of multiple statements. ---------- assignee: terry.reedy components: IDLE messages: 350000 nosy: cheryl.sabella, rhettinger, taleinat, terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE Shell: isolate user code input type: behavior versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 07:52:23 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 20 Aug 2019 11:52:23 +0000 Subject: [issue7676] IDLE shell shouldn't use TABs In-Reply-To: <1263213381.47.0.181451927584.issue7676@psf.upfronthosting.co.za> Message-ID: <1566301943.81.0.383692724021.issue7676@roundup.psfhosted.org> Terry J. Reedy added the comment: I think that using tabs for Shell indents is IDLE's current worst design wart. But I agree with KBK (#1196946) that merely replacing tabs with spaces does not really solve the problem, which is the jagged physical margin consequent on physically indenting only the first line with a prompt. #37892 proposes to stop using tabs by implementing updated versions of the alternate fixes, 3 and 1, mentioned in msg151418 below. The alternate proposal will fix some other issues as well. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 08:11:02 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 12:11:02 +0000 Subject: [issue37732] Possible uninitialized variable in Objects/obmalloc.c In-Reply-To: <1564582636.59.0.312005293129.issue37732@roundup.psfhosted.org> Message-ID: <1566303062.29.0.759284165341.issue37732@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15059 pull_request: https://github.com/python/cpython/pull/15342 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 08:40:07 2019 From: report at bugs.python.org (Vinay Sharma) Date: Tue, 20 Aug 2019 12:40:07 +0000 Subject: [issue37754] Persistence of Shared Memory Segment after process exits In-Reply-To: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> Message-ID: <1566304807.62.0.137309727552.issue37754@roundup.psfhosted.org> Change by Vinay Sharma : ---------- type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 08:44:37 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 12:44:37 +0000 Subject: [issue37732] Possible uninitialized variable in Objects/obmalloc.c In-Reply-To: <1564582636.59.0.312005293129.issue37732@roundup.psfhosted.org> Message-ID: <1566305077.73.0.28180039779.issue37732@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 30e5aff5fb0e3841107ddd4539a1f5b8521c80fb by Victor Stinner in branch '3.8': bpo-37732: Fix GCC warning in _PyObject_Malloc() (GH-15333) (GH-15342) https://github.com/python/cpython/commit/30e5aff5fb0e3841107ddd4539a1f5b8521c80fb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 08:48:29 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 12:48:29 +0000 Subject: [issue37732] Possible uninitialized variable in Objects/obmalloc.c In-Reply-To: <1564582636.59.0.312005293129.issue37732@roundup.psfhosted.org> Message-ID: <1566305309.31.0.289284359497.issue37732@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15060 pull_request: https://github.com/python/cpython/pull/15343 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 09:30:47 2019 From: report at bugs.python.org (Riccardo Schirone) Date: Tue, 20 Aug 2019 13:30:47 +0000 Subject: [issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699) In-Reply-To: <1495638091.75.0.96439752743.issue30458@psf.upfronthosting.co.za> Message-ID: <1566307847.06.0.517487903449.issue30458@roundup.psfhosted.org> Riccardo Schirone added the comment: Will the flaw outlined in https://bugs.python.org/issue30458#msg347282 be fixed in python itself? If so, I think a CVE for python should be requested to MITRE (I can request one, in that case). Moreover, does it make sense to create a new bug to track the new issue? This bug already references 3 CVEs and it would probably just create more confusion to reference a 4th. What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 10:11:57 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 20 Aug 2019 14:11:57 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566310317.05.0.297267092272.issue37884@roundup.psfhosted.org> Mark Dickinson added the comment: > This issue if for optimization only. It does not expand the math module API. I think it does, though. The PR adds something to the math module that's tested, that needs to be maintained for other modules to work, and that's imported for use in another module; that smells like an element of the API to me, even with the leading underscore in the name. Other Python implementations would also need to implement math._as_integer_ratio for the pure Python fractions code to continue working. If we're going to expand the math module API to include such a function (and I don't think we should), we should do it properly: remove the leading underscore, and add documentation. But as you say, that's a separate issue. I'm with Raymond here; I don't think this change is desirable for the math module, either with or without the leading underscore in the name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 10:29:26 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 14:29:26 +0000 Subject: [issue37732] Possible uninitialized variable in Objects/obmalloc.c In-Reply-To: <1564582636.59.0.312005293129.issue37732@roundup.psfhosted.org> Message-ID: <1566311366.6.0.785241873885.issue37732@roundup.psfhosted.org> STINNER Victor added the comment: New changeset c9a484a1e76384680b90454018389465760dbeae by Victor Stinner in branch '3.7': bpo-37732: Fix GCC warning in _PyObject_Malloc() (GH-15333) (GH-15342) (GH-15343) https://github.com/python/cpython/commit/c9a484a1e76384680b90454018389465760dbeae ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 10:30:56 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 14:30:56 +0000 Subject: [issue37732] Possible uninitialized variable in Objects/obmalloc.c In-Reply-To: <1564582636.59.0.312005293129.issue37732@roundup.psfhosted.org> Message-ID: <1566311456.26.0.882669639234.issue37732@roundup.psfhosted.org> STINNER Victor added the comment: Thanks Joannah for the bug report. I fixed the warning on 3.7, 3.8 and master branches. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 10:46:49 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 14:46:49 +0000 Subject: [issue15913] Add PyBuffer_SizeFromFormat() C helper for struct.calcsize() In-Reply-To: <1347312444.09.0.484126652005.issue15913@psf.upfronthosting.co.za> Message-ID: <1566312409.16.0.664475810929.issue15913@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 9e66aba99925eebacfe137d9deb0ef1fdbc2d5db by Victor Stinner (Joannah Nanjekye) in branch 'master': bpo-15913: Implement PyBuffer_SizeFromFormat() (GH-13873) https://github.com/python/cpython/commit/9e66aba99925eebacfe137d9deb0ef1fdbc2d5db ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 10:47:47 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 14:47:47 +0000 Subject: [issue15913] Add PyBuffer_SizeFromFormat() C helper for struct.calcsize() In-Reply-To: <1347312444.09.0.484126652005.issue15913@psf.upfronthosting.co.za> Message-ID: <1566312467.65.0.926675037426.issue15913@roundup.psfhosted.org> STINNER Victor added the comment: Joannah Nanjekye implemented the function, thanks. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 10:57:04 2019 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 20 Aug 2019 14:57:04 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566313024.51.0.803327570339.issue37531@roundup.psfhosted.org> Jeremy Kloth added the comment: It seems that an issue still exists. https://buildbot.python.org/all/#/builders/130/builds/1050 has been running for nearly 9 hours at this point. I can leave it "stuck" if there is some diagnostics that would be beneficial. But I would prefer not to have this impeding other testing for too long. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 11:08:41 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 20 Aug 2019 15:08:41 +0000 Subject: [issue37891] Exceptions tutorial page does not mention raise from In-Reply-To: <1566285667.91.0.992762773609.issue37891@roundup.psfhosted.org> Message-ID: <1566313721.85.0.0612568213789.issue37891@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks for spotting this omission. Would you like to submit a PR with a short paragraph on exception chaining and "raise from"? ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 11:16:26 2019 From: report at bugs.python.org (Eryk Sun) Date: Tue, 20 Aug 2019 15:16:26 +0000 Subject: [issue37754] Persistence of Shared Memory Segment after process exits In-Reply-To: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> Message-ID: <1566314186.43.0.416576096662.issue37754@roundup.psfhosted.org> Eryk Sun added the comment: > PS: I personally believe from my experience that shared memory > segments should outlive the process, unless specified otherwise. > Also, a argument persist=True, can be added which can ensure > that the shared_memory segment outlives the process, and can be > used by processes which are spawned later. In terms of providing "consistent behavior across platforms that can be reasonably supported", the behavior suggested above could not reasonably be supported in Windows. The Section (shared memory) object itself is not a file. It gets created in the object namespace, either globally in "\BaseNamedObjects" or in an interactive session's "\Sessions\\BaseNamedObjects". By default, kernel objects are temporary. Creating permanent named objects requires SeCreatePermanentPrivilege, which by default is only granted to SYSTEM (sort of like root in Unix). For an object to be accessible across sessions and outlive an interactive session, it needs to be global. Creating global Section objects requires SeCreateGlobalPrivilege, which by default is only granted to administrators and service accounts. Also, the Windows API has no capability to create permanent objects, so this would require the NT API functions NtMakePermanentObject (undocumented, added in NT 5.1) and NtMakeTemporaryObject. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 11:33:04 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 15:33:04 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566315184.75.0.692964470864.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: I just tested the 3.7 branch manually: regrtest works as expected. I'm using this local changes: diff --git a/Lib/test/libregrtest/runtest.py b/Lib/test/libregrtest/runtest.py index e7dce180cb..7d996d6918 100644 --- a/Lib/test/libregrtest/runtest.py +++ b/Lib/test/libregrtest/runtest.py @@ -119,7 +119,7 @@ def _runtest(ns, test_name): use_timeout = (ns.timeout is not None) if use_timeout: - faulthandler.dump_traceback_later(ns.timeout, exit=True) + pass #faulthandler.dump_traceback_later(ns.timeout, exit=True) start_time = time.perf_counter() try: diff --git a/Lib/test/test_os.py b/Lib/test/test_os.py index 8032da0530..e21399c840 100644 --- a/Lib/test/test_os.py +++ b/Lib/test/test_os.py @@ -89,6 +89,7 @@ class FileTests(unittest.TestCase): tearDown = setUp def test_access(self): + import time; time.sleep(3600) f = os.open(support.TESTFN, os.O_CREAT|os.O_RDWR) os.close(f) self.assertTrue(os.access(support.TESTFN, os.W_OK)) Then I ran: vstinner at apu$ ./python -m test -j2 test_os -m test_access --timeout=3 Run tests in parallel using 2 child processes 0:00:04 load avg: 0.59 [1/1/1] test_os timed out (4 sec 512 ms) == Tests result: FAILURE == 1 test failed: test_os Total duration: 4 sec 545 ms Tests result: FAILURE As you can see, test_os is killed after 4.5 seconds, as expected (it uses timeout x 1.5, since faulthandler is supposed to be first watchdog with timeout seconds). -- Maybe something is wrong with test_concurrent_futures on Windows. Maybe subprocess.Popen.kill() is unable to kill the process immediately for an unknown reason? Or maybe subprocess.Popen.communicate(timeout=self.timeout) didn't fail with TimeoutExpired? Sadly, libregrtest is quite when it kills a worker process because of timeout, since the following output should be enough to understand what happened. But here the worker was not killed, or failed to be killed, or something else... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 11:36:48 2019 From: report at bugs.python.org (Steve Dower) Date: Tue, 20 Aug 2019 15:36:48 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566315408.25.0.0480244219819.issue37834@roundup.psfhosted.org> Steve Dower added the comment: The latest PR also fixes issue1311 and issue20541 properly (os.path.exists("NUL") now returns True). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 11:39:55 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 15:39:55 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566315595.31.0.639791933029.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: > I can leave it "stuck" if there is some diagnostics that would be beneficial. Can you check the process hierarchy? I would like to know how many worker processes are still running under the main regrtest process. I expect to see exactly one. I don't know how to investigate more on such issue on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 11:42:42 2019 From: report at bugs.python.org (Tim Peters) Date: Tue, 20 Aug 2019 15:42:42 +0000 Subject: [issue37893] pow() should disallow inverse when modulus is +-1 Message-ID: <1566315762.28.0.408407507817.issue37893@roundup.psfhosted.org> New submission from Tim Peters : For example, these should all raise ValueError instead: >>> pow(2, -1, 1) 0 >>> pow(1, -1, 1) 0 >>> pow(0, -1, 1) 0 >>> pow(2, -1, -1) 0 >>> pow(1, -1, -1) 0 >>> pow(0, -1, -1) 0 ---------- components: Library (Lib) messages: 350015 nosy: mark.dickinson, tim.peters priority: normal severity: normal stage: needs patch status: open title: pow() should disallow inverse when modulus is +-1 type: behavior versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 11:53:49 2019 From: report at bugs.python.org (Batuhan) Date: Tue, 20 Aug 2019 15:53:49 +0000 Subject: [issue37893] pow() should disallow inverse when modulus is +-1 In-Reply-To: <1566315762.28.0.408407507817.issue37893@roundup.psfhosted.org> Message-ID: <1566316429.28.0.917788535135.issue37893@roundup.psfhosted.org> Batuhan added the comment: Can i work on this? ---------- nosy: +BTaskaya _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 11:55:09 2019 From: report at bugs.python.org (Jeremy Kloth) Date: Tue, 20 Aug 2019 15:55:09 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1566315595.31.0.639791933029.issue37531@roundup.psfhosted.org> Message-ID: Jeremy Kloth added the comment: > Can you check the process hierarchy? I would like to know how many worker processes are still running under the main regrtest process. I expect to see exactly one. I don't know how to investigate more on such issue on Windows. There are no child processes of the main test process. There are 5 orphaned processes from multiprocessing. Their parent process is gone (assuming the parent_pid argument is correct). There is also an orphaned typeperf.exe process, probably also from the killed process. ---------- nosy: +jeremy.kloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 11:56:49 2019 From: report at bugs.python.org (Tim Peters) Date: Tue, 20 Aug 2019 15:56:49 +0000 Subject: [issue37893] pow() should disallow inverse when modulus is +-1 In-Reply-To: <1566315762.28.0.408407507817.issue37893@roundup.psfhosted.org> Message-ID: <1566316609.36.0.346983083115.issue37893@roundup.psfhosted.org> Tim Peters added the comment: @Batuhan, fine by me if you want to take this on! It should be relatively easy. But Mark wrote the code, so it's really up to him. While I doubt this, he may even argue that it's working correctly already ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 11:59:37 2019 From: report at bugs.python.org (Wator Sead) Date: Tue, 20 Aug 2019 15:59:37 +0000 Subject: [issue37894] [win] shutil.which can not find the path if 'cmd' include directory path and not include extension name Message-ID: <1566316777.4.0.882745227499.issue37894@roundup.psfhosted.org> New submission from Wator Sead : The current code is: ... if os.path.dirname(cmd): if _access_check(cmd, mode): return cmd return None ... In Windows, if 'cmd' include directory path and not include extension name, it return 'None'. e.g. a file's path is 'd:\dir\app.exe', call shutil.which with 'cmd=="d:\dir\app"'. How about this patch: ... if os.path.dirname(cmd): path, cmd = os.path.split(cmd) ... ---------- components: Library (Lib) messages: 350019 nosy: seahoh priority: normal severity: normal status: open title: [win] shutil.which can not find the path if 'cmd' include directory path and not include extension name type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 12:04:04 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 16:04:04 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566317044.89.0.415826267627.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: (I reopen the issue.) "There are no child processes of the main test process. There are 5 orphaned processes from multiprocessing. Their parent process is gone (assuming the parent_pid argument is correct)." Oh wow, that's really strange. I would expect that regrtest main process has one worker process: "test_concurrent_futures". https://buildbot.python.org/all/#/builders/130/builds/1050 C:\buildbot.python.org\3.7.kloth-win64\build>"C:\buildbot.python.org\3.7.kloth-win64\build\PCbuild\amd64\python_d.exe" -u -Wd -E -bb -m test -uall -rwW --slowest --timeout 1200 --fail-env-changed -j1 -j2 -j4 --timeout 900 == CPython 3.7.4+ (heads/3.7:02c1457, Aug 20 2019, 00:03:57) [MSC v.1900 64 bit (AMD64)] == Windows-7-6.1.7601-SP1 little-endian == cwd: C:\buildbot.python.org\3.7.kloth-win64\build\build\test_python_5524 == CPU count: 4 == encodings: locale=cp1252, FS=utf-8 Using random seed 1058030 Run tests in parallel using 4 child processes 0:00:01 load avg: 0.00 [ 1/416] test_call passed 0:00:02 load avg: 0.00 [ 2/416] test_genexps passed ... 0:12:46 load avg: 2.30 [412/416] test_threaded_import passed -- running: test_concurrent_futures (8 min 42 sec) 0:12:47 load avg: 2.30 [413/416] test_email passed -- running: test_concurrent_futures (8 min 43 sec) 0:12:50 load avg: 2.19 [414/416] test_bytes passed -- running: test_concurrent_futures (8 min 46 sec) 0:12:55 load avg: 2.02 [415/416] test_timeout passed -- running: test_concurrent_futures (8 min 52 sec) running: test_concurrent_futures (9 min 22 sec) running: test_concurrent_futures (9 min 52 sec) running: test_concurrent_futures (10 min 22 sec) ... running: test_concurrent_futures (9 hour 51 min) running: test_concurrent_futures (9 hour 51 min) running: test_concurrent_futures (9 hour 52 min) running: test_concurrent_futures (9 hour 52 min) running: test_concurrent_futures (9 hour 53 min) ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 12:36:14 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 20 Aug 2019 16:36:14 +0000 Subject: [issue37894] [win] shutil.which can not find the path if 'cmd' include directory path and not include extension name In-Reply-To: <1566316777.4.0.882745227499.issue37894@roundup.psfhosted.org> Message-ID: <1566318974.81.0.237273264125.issue37894@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 Aug 20 12:47:21 2019 From: report at bugs.python.org (Batuhan) Date: Tue, 20 Aug 2019 16:47:21 +0000 Subject: [issue37893] pow() should disallow inverse when modulus is +-1 In-Reply-To: <1566315762.28.0.408407507817.issue37893@roundup.psfhosted.org> Message-ID: <1566319641.52.0.167901949523.issue37893@roundup.psfhosted.org> Change by Batuhan : ---------- keywords: +patch pull_requests: +15061 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15344 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 13:12:07 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 20 Aug 2019 17:12:07 +0000 Subject: [issue37893] pow() should disallow inverse when modulus is +-1 In-Reply-To: <1566315762.28.0.408407507817.issue37893@roundup.psfhosted.org> Message-ID: <1566321127.45.0.878897263449.issue37893@roundup.psfhosted.org> Mark Dickinson added the comment: > While I doubt this, he may even argue that it's working correctly already ;-) Yes, I'd argue exactly that. There's nothing ill-defined about working modulo +/-1. Z/1Z is a perfectly-well-defined ring. What's the motivation for this change? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 13:13:41 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 20 Aug 2019 17:13:41 +0000 Subject: [issue37893] pow() should disallow inverse when modulus is +-1 In-Reply-To: <1566315762.28.0.408407507817.issue37893@roundup.psfhosted.org> Message-ID: <1566321221.81.0.271586730899.issue37893@roundup.psfhosted.org> Mark Dickinson added the comment: > Z/1Z is a perfectly-well-defined ring. More to the point, it's a perfectly well-defined ring in which every element is invertible. That's why the Euler phi function has phi(1) = 1 (rather than phi(1) = 0), for example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 13:21:28 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 17:21:28 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566321688.09.0.288193825283.issue37531@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15062 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/15345 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 13:26:08 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 20 Aug 2019 17:26:08 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566321968.52.0.508526549257.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: I wrote PR 15345 to enhance regrtest timeout: more logs, more timeouts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 13:38:19 2019 From: report at bugs.python.org (Tim Peters) Date: Tue, 20 Aug 2019 17:38:19 +0000 Subject: [issue37893] pow() should disallow inverse when modulus is +-1 In-Reply-To: <1566315762.28.0.408407507817.issue37893@roundup.psfhosted.org> Message-ID: <1566322699.74.0.94020235135.issue37893@roundup.psfhosted.org> Tim Peters added the comment: Yup, you have a point there! :-) I guess I'm just not used to 0 being a multiplicative identity. Don't know what other systems do. Playing with Maxima, modulo 1 it seems to think 0 is the inverse of everything _except_ for 0. `inv_mod(0, 1)` returns `false`. Modulo -1, everything I tried returned `false`. Which makes less sense to me. Fine by me if you want to close this as "not a bug". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 13:47:23 2019 From: report at bugs.python.org (Tim Peters) Date: Tue, 20 Aug 2019 17:47:23 +0000 Subject: [issue37893] pow() should disallow inverse when modulus is +-1 In-Reply-To: <1566315762.28.0.408407507817.issue37893@roundup.psfhosted.org> Message-ID: <1566323243.3.0.0617249050315.issue37893@roundup.psfhosted.org> Tim Peters added the comment: Mark, to save you the hassle, I'm closing this myself now. Thanks for the feedback! ---------- assignee: -> tim.peters resolution: -> not a bug stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 13:48:47 2019 From: report at bugs.python.org (Abhilash Raj) Date: Tue, 20 Aug 2019 17:48:47 +0000 Subject: [issue32793] smtplib: duplicated debug message In-Reply-To: <1518080718.92.0.467229070634.issue32793@psf.upfronthosting.co.za> Message-ID: <1566323327.1.0.834607453745.issue32793@roundup.psfhosted.org> Abhilash Raj added the comment: Removing 2.7 which only accepts security patches. ---------- nosy: +maxking versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 13:52:37 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 20 Aug 2019 17:52:37 +0000 Subject: [issue32793] smtplib: duplicated debug message In-Reply-To: <1518080718.92.0.467229070634.issue32793@psf.upfronthosting.co.za> Message-ID: <1566323557.33.0.648131787584.issue32793@roundup.psfhosted.org> miss-islington added the comment: New changeset 46a7564578f208df1e0c54fc0520d3b7ca32c981 by Miss Islington (bot) (Zackery Spytz) in branch 'master': bpo-32793: Fix a duplicate debug message in smtplib (GH-15341) https://github.com/python/cpython/commit/46a7564578f208df1e0c54fc0520d3b7ca32c981 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 13:53:52 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 20 Aug 2019 17:53:52 +0000 Subject: [issue30458] [security][CVE-2019-9740][CVE-2019-9947] HTTP Header Injection (follow-up of CVE-2016-5699) In-Reply-To: <1495638091.75.0.96439752743.issue30458@psf.upfronthosting.co.za> Message-ID: <1566323632.97.0.592477343856.issue30458@roundup.psfhosted.org> Gregory P. Smith added the comment: I'm not a fan of CVE numbers in general, people have been creating too many of those. But that also means I just don't care if someone does. Having a CVE entry is not a way to claim something is important. This issue is still open and can be used to track dealing with the host. ---------- assignee: larry -> keywords: +security_issue stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 14:21:58 2019 From: report at bugs.python.org (Brett Cannon) Date: Tue, 20 Aug 2019 18:21:58 +0000 Subject: [issue37890] Modernize several tests in test_importlib In-Reply-To: <1566269296.72.0.828504709815.issue37890@roundup.psfhosted.org> Message-ID: <1566325318.82.0.663582276889.issue37890@roundup.psfhosted.org> Brett Cannon added the comment: What Serhiy said. :) There's code to be able to easily test both builtins.__import__ and importlib.__import__ in tests so that there's no drift between the two implementations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 14:26:03 2019 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 20 Aug 2019 18:26:03 +0000 Subject: [issue37893] pow() should disallow inverse when modulus is +-1 In-Reply-To: <1566315762.28.0.408407507817.issue37893@roundup.psfhosted.org> Message-ID: <1566325563.98.0.941656425176.issue37893@roundup.psfhosted.org> Mark Dickinson added the comment: > I guess I'm just not used to 0 being a multiplicative identity. Yes, there's a whole generation of mathematicians who believe (wrongly) that "0 != 1" is one of the ring axioms. But it turns out that excluding the zero ring from the category of (commutative, unital) rings isn't helpful, and causes all sorts of otherwise universal constructs (quotients, localizations, categorical limits in general) to have only conditional existence. So nowadays most (but not all) people accept that the zero ring has the same right to exist as any other commutative ring. Integral domains are another matter, of course: there you really _do_ want to insist that 1 != 0, though what you're really insisting is that any finite product of nonzero elements should be nonzero, and 1 != 0 is just the special case of that rule for the empty product, while x*y !=0 for x != 0 and y != 0 is the special case for two arguments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 14:26:19 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 20 Aug 2019 18:26:19 +0000 Subject: [issue37895] test_logging hangs on an IPv6-only host Message-ID: <1566325579.16.0.877260560963.issue37895@roundup.psfhosted.org> New submission from Gregory P. Smith : test_logging hangs when run on an IPv6-only host. (127.0.0.1 isn't even available) test_listen_config_10_ok (test.test_logging.ConfigDictTest) ... Exception in thread Thread-3: Traceback (most recent call last): File "/home/greg/oss/cpython/Lib/threading.py", line 938, in _bootstrap_inner self.run() File "/home/greg/oss/cpython/Lib/logging/config.py", line 918, in run server = self.rcvr(port=self.port, handler=self.hdlr, File "/home/greg/oss/cpython/Lib/logging/config.py", line 885, in __init__ ThreadingTCPServer.__init__(self, (host, port), handler) File "/home/greg/oss/cpython/Lib/socketserver.py", line 452, in __init__ self.server_bind() File "/home/greg/oss/cpython/Lib/socketserver.py", line 466, in server_bind self.socket.bind(self.server_address) OSError: [Errno 99] Cannot assign requested address possibly more, but it's hung here. I'm preparing an IPv6-only buildbot. ---------- assignee: gregory.p.smith components: Tests messages: 350031 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: test_logging hangs on an IPv6-only host type: behavior versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 14:30:31 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 20 Aug 2019 18:30:31 +0000 Subject: [issue37896] test_multiprocessing_fork hangs on an IPv6-only host Message-ID: <1566325831.71.0.21098480947.issue37896@roundup.psfhosted.org> New submission from Gregory P. Smith : It winds up stuck on a leftover process: test_import (test.test_multiprocessing_fork._TestImportStar) ... ok Warning -- Dangling processes: {} Which is likely related to one of the other numerous failure ERRORs further up in the log. I'm preparing an IPv6-only buildbot ---------- assignee: gregory.p.smith components: Tests messages: 350032 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: test_multiprocessing_fork hangs on an IPv6-only host type: behavior versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 14:32:15 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 20 Aug 2019 18:32:15 +0000 Subject: [issue37897] test_asyncio hangs on an IPv6-only host Message-ID: <1566325935.2.0.450737551586.issue37897@roundup.psfhosted.org> New submission from Gregory P. Smith : test_drain_raises (test.test_asyncio.test_streams.StreamTests) ... Exception in thread Thread-20: Traceback (most recent call last): File "/home/greg/oss/cpython/Lib/threading.py", line 938, in _bootstrap_inner self.run() File "/home/greg/oss/cpython/Lib/threading.py", line 876, in run self._target(*self._args, **self._kwargs) File "/home/greg/oss/cpython/Lib/test/test_asyncio/test_streams.py", line 951, in server with socket.create_server(('localhost', 0)) as sock: File "/home/greg/oss/cpython/Lib/socket.py", line 804, in create_server raise error(err.errno, msg) from None OSError: [Errno 99] Cannot assign requested address (while attempting to bind on address ('localhost', 0)) I'm preparing an IPv6-only buildbot. (there is no IPv4 localhost) ---------- assignee: gregory.p.smith components: Tests messages: 350033 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: test_asyncio hangs on an IPv6-only host versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 14:33:34 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 20 Aug 2019 18:33:34 +0000 Subject: [issue37898] test_httpservers hangs on an IPv6-only host Message-ID: <1566326014.38.0.490683386628.issue37898@roundup.psfhosted.org> New submission from Gregory P. Smith : test_err (test.test_httpservers.RequestHandlerLoggingTestCase) ... Exception in thread Thread-1: Traceback (most recent call last): File "/home/greg/oss/cpython/Lib/threading.py", line 938, in _bootstrap_inner self.run() File "/home/greg/oss/cpython/Lib/test/test_httpservers.py", line 50, in run self.server = HTTPServer(('localhost', 0), self.request_handler) File "/home/greg/oss/cpython/Lib/socketserver.py", line 452, in __init__ self.server_bind() File "/home/greg/oss/cpython/Lib/http/server.py", line 137, in server_bind socketserver.TCPServer.server_bind(self) File "/home/greg/oss/cpython/Lib/socketserver.py", line 466, in server_bind self.socket.bind(self.server_address) OSError: [Errno 99] Cannot assign requested address I'm preparing an IPv6-only buildbot. There is no IPv4 localhost. ---------- assignee: gregory.p.smith components: Tests messages: 350034 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: test_httpservers hangs on an IPv6-only host type: behavior versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 14:34:29 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 20 Aug 2019 18:34:29 +0000 Subject: [issue37899] test_xmlrpc hangs on an IPv6-only host Message-ID: <1566326069.96.0.170799041894.issue37899@roundup.psfhosted.org> New submission from Gregory P. Smith : test_404 (test.test_xmlrpc.SimpleServerTestCase) ... Exception in thread Thread-1: Traceback (most recent call last): File "/home/greg/oss/cpython/Lib/threading.py", line 938, in _bootstrap_inner self.run() File "/home/greg/oss/cpython/Lib/threading.py", line 876, in run self._target(*self._args, **self._kwargs) File "/home/greg/oss/cpython/Lib/test/test_xmlrpc.py", line 619, in http_server serv.server_bind() File "/home/greg/oss/cpython/Lib/socketserver.py", line 466, in server_bind self.socket.bind(self.server_address) OSError: [Errno 99] Cannot assign requested address I'm preparing an IPv6-only buildbot. There is no IPv4 localhost. ---------- assignee: gregory.p.smith components: Tests messages: 350035 nosy: gregory.p.smith priority: normal severity: normal status: open title: test_xmlrpc hangs on an IPv6-only host versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 14:52:16 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Tue, 20 Aug 2019 18:52:16 +0000 Subject: [issue37891] Exceptions tutorial page does not mention raise from In-Reply-To: <1566285667.91.0.992762773609.issue37891@roundup.psfhosted.org> Message-ID: <1566327136.01.0.876523670032.issue37891@roundup.psfhosted.org> Srinivas Nyayapati added the comment: In case Niels Albers is not interested, can I submit a PR? I noticed the linked raise reference documentation from the tutorial having details on exception chaining (https://docs.python.org/3.7/reference/simple_stmts.html#raise). Does it make sense to mention exception chaining in the tutorial and say "read details in the reference docs"? Or as you mentioned.. just write a short paragraph on exception chaining and give an example in the tutorial? ---------- nosy: +shireenrao _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 15:21:32 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 20 Aug 2019 19:21:32 +0000 Subject: [issue37891] Exceptions tutorial page does not mention raise from In-Reply-To: <1566285667.91.0.992762773609.issue37891@roundup.psfhosted.org> Message-ID: <1566328892.56.0.674644574026.issue37891@roundup.psfhosted.org> Raymond Hettinger added the comment: Please give Niel a chance to submit wording, even a post here on the tracker will be fine. We usually defer to the person who actually encountered the issue. If after a week or so, there is no response, you can pick this up. Try to be minimal with it and avoid the temptation to go gonzo. The "from" part of exception semantics is one of its most minor and easily ignored features. Accordingly, it should get minimal space in the tutorial and probably doesn't even warrant an example if a simple, clear sentence will suffice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 16:26:53 2019 From: report at bugs.python.org (Kevin Wojniak) Date: Tue, 20 Aug 2019 20:26:53 +0000 Subject: [issue37900] [urllib] proxy_bypass_registry doesn't handle invalid proxy override values Message-ID: <1566332813.63.0.906100778728.issue37900@roundup.psfhosted.org> New submission from Kevin Wojniak : proxy_bypass_registry() will split the ProxyOverride registry key by semicolon. Then for each value it uses that value as a regular expression pattern with match(). However, if this value is not a valid regular expression, then match() will throw an exception that goes uncaught. This then breaks the loop and prevents the function from working correctly on other valid input. It's easy to reproduce: 1. Set this registry key to 1 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable 2. Set HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyOverride to this value (create as a string if necessary): []-78; 3. Call urllib.proxy_bypass() My suggestion for a fix would be to catch exceptions from match() in the loop and continue the loop on error. ---------- components: Windows messages: 350038 nosy: kwojniak_box, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: [urllib] proxy_bypass_registry doesn't handle invalid proxy override values type: crash versions: Python 2.7, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 18:41:23 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 20 Aug 2019 22:41:23 +0000 Subject: [issue37901] 21 tests fail when run on an IPv6-only host Message-ID: <1566340883.47.0.899841913634.issue37901@roundup.psfhosted.org> New submission from Gregory P. Smith : 21 tests failed: test_asynchat test_asyncore test_docxmlrpc test_eintr test_epoll test_ftplib test_httplib test_imaplib test_multiprocessing_forkserver test_multiprocessing_spawn test_nntplib test_os test_poplib test_robotparser test_smtplib test_socket test_ssl test_support test_telnetlib test_urllib2_localnet test_wsgiref This is a rollup tracking issue. I've got an IPv6-only future buildbot host with which to run an diagnose these for fixes. Of note there is no IPv4 localhost. If there are larger problems I may spawn child bugs for specific issues off of this one. (I already filed separate issues about 5 other tests that hang rather than fail) ---------- assignee: gregory.p.smith components: Tests messages: 350039 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: 21 tests fail when run on an IPv6-only host type: behavior versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 19:40:39 2019 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 20 Aug 2019 23:40:39 +0000 Subject: [issue34690] Store startup modules as C structures for 20%+ startup speed improvement In-Reply-To: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za> Message-ID: <1566344439.53.0.221215534429.issue34690@roundup.psfhosted.org> Change by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 19:49:17 2019 From: report at bugs.python.org (Kyle Stanley) Date: Tue, 20 Aug 2019 23:49:17 +0000 Subject: [issue37890] Modernize several tests in test_importlib In-Reply-To: <1566269296.72.0.828504709815.issue37890@roundup.psfhosted.org> Message-ID: <1566344957.66.0.473955431282.issue37890@roundup.psfhosted.org> Kyle Stanley added the comment: Ah okay, I wasn't sure what exactly would be involved with the "modernization" process, so those points were just rough ideas more than anything. I haven't started working on anything yet since I figured it'd be worthwhile to wait for approval first. > 1) __import__() can be used for purpose. I would not change this. Okay, I'll keep that part as is then. This idea was primarily based on importlib's documentation: "Programmatic importing of modules should use import_module() instead of [importlib.__import__()]" But that probably applies more to users of importlib, rather than the internal tests for it. That would make sense. 3) How would you distinguish the case when the module have an attribute with the value is None and when it does not have the attribute at all? This information would lost with your change. Good point. This might be a decent way to prevent the AttributeErrors, but still allows for differentiation of actual None values: ``` try: self.assertEqual(getattr(module, var), 1) except AttributeError: self.fail(f"{module} should have attribute {var}") ``` Personally I think it makes a bit more sense to use self.fail() with a helpful message rather than raising errors within the tests. There's a comment on line 56, "# self.fail() ?", which gave me this idea. Is there a particular preference in the context of Python's tests? Also, do either of you (or anyone else) have any ideas for other modernization improvements that could be made to either test_pkg_import.py or to the other two? In the meantime, I can start working on ideas (2) and (4) if those ones would be appropriate. (2) should be fairly straightforward, but (4) will probably be a bit more subjective. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 20:16:22 2019 From: report at bugs.python.org (Tim Peters) Date: Wed, 21 Aug 2019 00:16:22 +0000 Subject: [issue37893] pow() should disallow inverse when modulus is +-1 In-Reply-To: <1566315762.28.0.408407507817.issue37893@roundup.psfhosted.org> Message-ID: <1566346582.92.0.933388051482.issue37893@roundup.psfhosted.org> Tim Peters added the comment: I don't have a problem with the trivial ring - I wasn't being that high-minded ;-) I was testing a different inverse algorithm, and in the absence of errors checked that minv(a, m) * a % m == 1 for various a and m >= 0. Of course that failed using pow(a, -1, m) instead when m=1. Offhand, I couldn't imagine a plausible use case for finding an inverse mod 1 - and still can't ;-) In abstract algebra, sure - but for concrete numerical computation? Oh well. In any case, testing (minv(a, m) * a - 1) % m == 0 instead appears to work for all non-error cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 21:09:47 2019 From: report at bugs.python.org (Kyle Stanley) Date: Wed, 21 Aug 2019 01:09:47 +0000 Subject: [issue37890] Modernize several tests in test_importlib In-Reply-To: <1566269296.72.0.828504709815.issue37890@roundup.psfhosted.org> Message-ID: <1566349787.64.0.169448370309.issue37890@roundup.psfhosted.org> Kyle Stanley added the comment: > This might be a decent way to prevent the AttributeErrors, but still allows for differentiation of actual None values Another alternative solution might be to use hasattr() before getattr(), if it is not desirable for test_pkg_import.py to raise exceptions: ``` self.assertTrue(hasattr(module, var), msg=f"{module} should have attribute {var}") self.assertEqual(getattr(module, var), 1) ``` That would follow more of a LBYL style, but I know that EAFP is more common within Python. The better alternative depends on the answer to my earlier question regarding exceptions being raised from the unit tests: > Is there a particular preference in the context of Python's tests? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 21:54:40 2019 From: report at bugs.python.org (George Zhang) Date: Wed, 21 Aug 2019 01:54:40 +0000 Subject: [issue37902] Add scrolling for IDLE browsers Message-ID: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> New submission from George Zhang : I've just started using IDLE's module/path browsers and they offer a lot! Putting aside the issue of them opening in separate windows, they have a small change that could be made to improve them. Both browsers have scrollbars, but (for me at least) I cannot scroll using my mouse. I propose adding support for scrolling similar to the editor/shell windows. ---------- assignee: terry.reedy components: IDLE messages: 350043 nosy: GeeVye, terry.reedy priority: normal severity: normal status: open title: Add scrolling for IDLE browsers type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 21:57:28 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 21 Aug 2019 01:57:28 +0000 Subject: [issue37901] 21 tests fail when run on an IPv6-only host In-Reply-To: <1566340883.47.0.899841913634.issue37901@roundup.psfhosted.org> Message-ID: <1566352648.13.0.14825738833.issue37901@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 22:09:28 2019 From: report at bugs.python.org (Franklin Yu) Date: Wed, 21 Aug 2019 02:09:28 +0000 Subject: [issue29427] Option to skip padding for base64 urlsafe encoding/decoding In-Reply-To: <1486085117.43.0.563120448637.issue29427@psf.upfronthosting.co.za> Message-ID: <1566353368.11.0.575188938711.issue29427@roundup.psfhosted.org> Change by Franklin Yu : ---------- nosy: +Franklin Yu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 22:39:37 2019 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 21 Aug 2019 02:39:37 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566355177.0.0.248957960841.issue37531@roundup.psfhosted.org> Jeremy Kloth added the comment: Additional logging on failures is always welcome. Might I suggest that, in this case, regrtest treats this action as a hard fail so as to not got lost in the other transient failures (test_asyncio). By that I mean, either to not re-run, or to still be "failed" even after a successful re-run as this test_concurrent mishap is rare enough that I doubt it would happen twice in one build. Now for a brain dump. The process tree at this time: python.exe (buildbot) . cmd.exe (test step) .. python_d.exe (regrtest main) ... typepref.exe (load) ... .... typepref.exe (load for test_concurrent_futures) .... python_d.exe (multiprocessing pool) .... python_d.exe (multiprocessing pool) .... python_d.exe (multiprocessing pool) .... python_d.exe (multiprocessing pool) .... python_d.exe (multiprocessing pool) 1. To see how process termination played out, I killed the main regrtest process. This did not let the buildbot complete, but just sit there without any output. Also the typepref.exe process (and the failed multiprocessing pool processes) still lingered. 2. I then terminated the children* of the already terminated process. No change to the buildbot. [*] Windows doesn't really have the concept of a process tree 3. I then terminated the final typepref.exe process. The buildbot finally finished its test step. Given that typepref.exe also prevents completion, I believe the problem is in how we are spawning subprocesses. Maybe a process handle is being inherited by the spawned processes preventing it from fully terminating? I mention the process handle as it was listed as an open handle in Process Explorer for the regrtest process even though it had been terminated prior. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 23:29:54 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 21 Aug 2019 03:29:54 +0000 Subject: [issue35518] test_timeout uses blackhole.snakebite.net domain which doesn't exist anymore In-Reply-To: <1545044915.94.0.788709270274.issue35518@psf.upfronthosting.co.za> Message-ID: <1566358194.25.0.793809168759.issue35518@roundup.psfhosted.org> Change by Greg Price : ---------- keywords: +patch pull_requests: +15063 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15349 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 23:37:57 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 21 Aug 2019 03:37:57 +0000 Subject: [issue35518] test_timeout uses blackhole.snakebite.net domain which doesn't exist anymore In-Reply-To: <1545044915.94.0.788709270274.issue35518@psf.upfronthosting.co.za> Message-ID: <1566358677.16.0.932238066365.issue35518@roundup.psfhosted.org> Greg Price added the comment: I ran across this test when looking at especially slow files in the test suite: it turns out that not only is this service currently down, but the snakebite.net domain still exists, and as a result the test can end up waiting 20-30s before learning that the hosts can't be found and the test gets skipped. I agree with Benjamin's and Victor's comments -- the best solution would be to recreate the test, ideally as something that anyone (anyone with Docker installed, perhaps?) can just run locally. For now I've just sent GH-15349 as a one-line fix to skip the test, with a remark pointing at this issue. It's already getting skipped 100% of the time thanks to the handy `support.transient_internet` mechanism -- this just makes the skip (a) explicit in the source code, and (b) a lot faster. :-) ---------- nosy: +Greg Price _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 23:51:00 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 21 Aug 2019 03:51:00 +0000 Subject: [issue35518] test_timeout uses blackhole.snakebite.net domain which doesn't exist anymore In-Reply-To: <1545044915.94.0.788709270274.issue35518@psf.upfronthosting.co.za> Message-ID: <1566359460.87.0.656704862442.issue35518@roundup.psfhosted.org> Benjamin Peterson added the comment: New changeset 5b95a1507e349da5adae6d2ab57deac3bdd12f15 by Benjamin Peterson (Greg Price) in branch 'master': bpo-35518: Skip test that relies on a deceased network service. (GH-15349) https://github.com/python/cpython/commit/5b95a1507e349da5adae6d2ab57deac3bdd12f15 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 23:51:04 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 03:51:04 +0000 Subject: [issue35518] test_timeout uses blackhole.snakebite.net domain which doesn't exist anymore In-Reply-To: <1545044915.94.0.788709270274.issue35518@psf.upfronthosting.co.za> Message-ID: <1566359464.01.0.390960056103.issue35518@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15064 pull_request: https://github.com/python/cpython/pull/15350 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 23:51:10 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 03:51:10 +0000 Subject: [issue35518] test_timeout uses blackhole.snakebite.net domain which doesn't exist anymore In-Reply-To: <1545044915.94.0.788709270274.issue35518@psf.upfronthosting.co.za> Message-ID: <1566359470.14.0.18240403365.issue35518@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15065 pull_request: https://github.com/python/cpython/pull/15351 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 23:51:16 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 03:51:16 +0000 Subject: [issue35518] test_timeout uses blackhole.snakebite.net domain which doesn't exist anymore In-Reply-To: <1545044915.94.0.788709270274.issue35518@psf.upfronthosting.co.za> Message-ID: <1566359476.81.0.876085548764.issue35518@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15066 pull_request: https://github.com/python/cpython/pull/15352 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 20 23:58:46 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 21 Aug 2019 03:58:46 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566359926.41.0.821591422025.issue37902@roundup.psfhosted.org> Terry J. Reedy added the comment: I agree. We added mousewheel scrolling to editor just over a year ago and later added it to text views. But for the browsers, I want to factor out the common code. It is a bit tricky since the 3 major systems each send different events for the same action, and macOS has the opposite convention for how the text moves when pushing the wheel up. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 00:03:08 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 21 Aug 2019 04:03:08 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566360188.51.0.66283501192.issue37902@roundup.psfhosted.org> Terry J. Reedy added the comment: #31461 is the index issue for class browser. Mousewheel scrolling was listed without an issue. Now there is, and this has been added as a dependency. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 00:03:13 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 21 Aug 2019 04:03:13 +0000 Subject: [issue31461] IDLE: Enhance module browser In-Reply-To: <1505340167.3.0.497795629423.issue31461@psf.upfronthosting.co.za> Message-ID: <1566360193.67.0.821681849798.issue31461@roundup.psfhosted.org> Terry J. Reedy added the comment: #37902 Add mousewheel scrolling. ---------- dependencies: +Add scrolling for IDLE browsers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 00:09:00 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 04:09:00 +0000 Subject: [issue35518] test_timeout uses blackhole.snakebite.net domain which doesn't exist anymore In-Reply-To: <1545044915.94.0.788709270274.issue35518@psf.upfronthosting.co.za> Message-ID: <1566360540.3.0.748126115745.issue35518@roundup.psfhosted.org> miss-islington added the comment: New changeset 44f2c096804e8e3adc09400a59ef9c9ae843f339 by Miss Islington (bot) in branch '3.8': bpo-35518: Skip test that relies on a deceased network service. (GH-15349) https://github.com/python/cpython/commit/44f2c096804e8e3adc09400a59ef9c9ae843f339 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 00:11:28 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 04:11:28 +0000 Subject: [issue35518] test_timeout uses blackhole.snakebite.net domain which doesn't exist anymore In-Reply-To: <1545044915.94.0.788709270274.issue35518@psf.upfronthosting.co.za> Message-ID: <1566360688.82.0.432689914972.issue35518@roundup.psfhosted.org> miss-islington added the comment: New changeset b9d88e771238b5098842cad8a6ad624621f3f62e by Miss Islington (bot) in branch '3.7': bpo-35518: Skip test that relies on a deceased network service. (GH-15349) https://github.com/python/cpython/commit/b9d88e771238b5098842cad8a6ad624621f3f62e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 00:12:20 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 04:12:20 +0000 Subject: [issue35518] test_timeout uses blackhole.snakebite.net domain which doesn't exist anymore In-Reply-To: <1545044915.94.0.788709270274.issue35518@psf.upfronthosting.co.za> Message-ID: <1566360740.88.0.461855681376.issue35518@roundup.psfhosted.org> miss-islington added the comment: New changeset 198a0d622a696a4c234aa7866d6c15e38839cc76 by Miss Islington (bot) in branch '2.7': bpo-35518: Skip test that relies on a deceased network service. (GH-15349) https://github.com/python/cpython/commit/198a0d622a696a4c234aa7866d6c15e38839cc76 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 01:48:50 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 21 Aug 2019 05:48:50 +0000 Subject: [issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass In-Reply-To: <1564977335.6.0.0909548880632.issue37760@roundup.psfhosted.org> Message-ID: <1566366530.03.0.518542572465.issue37760@roundup.psfhosted.org> Greg Price added the comment: (A bit easy to miss in the way this thread gets displayed, so to highlight in a comment: GH-15265 is up, following the 5 other patches which have now all been merged. That's the one that replaces the length-18 tuples with a dataclass.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 02:47:13 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 21 Aug 2019 06:47:13 +0000 Subject: [issue37903] IDLE Shell sidebar. Message-ID: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org> New submission from Terry J. Reedy : This issue proposes to add a shell-specific sidebar to Shell. It follows-up #17535, which added a line-number sidebar to module editors and implements the first phase of #37892, which proposes that the single statement editing area of Shell should be strictly just that. Looking ahead to this issue, #17535 added both a generic Sidebar class and a specific LineNumber subclass. This issue proposes to add a 3 char wide ShellIO subclass that would mark the beginning of the blocks of text added to the Shell history area. Labels, such as '>>>', 'Out', 'Inp', and 'Err' would be used for the first line of user code input, program stdout, user response to input() (there is only one line), and program stderr (which includes tracebacks). I am not quite sure what to do with debug notices and warnings from the warning modules. Maybe use 'Con', maybe use Dbg and Wrn. I expect to test variations. As with LineNumber, the font face and size will the the same as in the text. The labels should use the highlight colors of their text block except that '>>>' should continue getting the 'console' colors. I thing the initial implementation should not response to clicks. After experimentation, we might decide that clicking on a label could select whole blocks, but I would like get the essential stuff right first. ---------- messages: 350054 nosy: taleinat, terry.reedy priority: normal severity: normal stage: test needed status: open title: IDLE Shell sidebar. type: behavior versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 02:47:57 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 21 Aug 2019 06:47:57 +0000 Subject: [issue37892] IDLE Shell: isolate user code input In-Reply-To: <1566301123.94.0.491748175182.issue37892@roundup.psfhosted.org> Message-ID: <1566370077.13.0.789424860276.issue37892@roundup.psfhosted.org> Terry J. Reedy added the comment: Adding a Shell sidebar is #37903. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 05:56:34 2019 From: report at bugs.python.org (Roee Nizan) Date: Wed, 21 Aug 2019 09:56:34 +0000 Subject: [issue30413] Add fnmatch.filterfalse function In-Reply-To: <1495286342.86.0.934515673373.issue30413@psf.upfronthosting.co.za> Message-ID: <1566381394.2.0.599119385028.issue30413@roundup.psfhosted.org> Roee Nizan added the comment: Was this abandoned? Is there a reason not to accept this? ---------- nosy: +Roee Nizan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 05:57:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 09:57:15 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566381435.68.0.846373345304.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: > .... typepref.exe (load for test_concurrent_futures) I don't understand why you get 2 typepref.exe process: only the main process should spawn one. Worker processes don't need it and should not spawn it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 05:59:23 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 09:59:23 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566381563.65.0.572179979749.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: New changeset de2d9eed8bc628533e1628b843cc4c7a5010f6e5 by Victor Stinner in branch 'master': bpo-37531: Enhance regrtest multiprocess timeout (GH-15345) https://github.com/python/cpython/commit/de2d9eed8bc628533e1628b843cc4c7a5010f6e5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 06:00:57 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 10:00:57 +0000 Subject: [issue37901] 21 tests fail when run on an IPv6-only host In-Reply-To: <1566340883.47.0.899841913634.issue37901@roundup.psfhosted.org> Message-ID: <1566381657.76.0.508014554719.issue37901@roundup.psfhosted.org> STINNER Victor added the comment: How do you configure a Linux box to disable IPv4? At least, disable IPv4 localhost? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 06:21:13 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 10:21:13 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566382873.93.0.469796556543.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: Oh, interesting: test_regrtest.test_multiprocessing_timeout() failed with a timeout on x86 Windows7 3.x. This build tested commit d33e46d17d33f9b918846982c02ddc17d897c9bc which is older than my "bpo-37531: Enhance regrtest multiprocess timeout (GH-15345)" change (older than commit de2d9eed8bc628533e1628b843cc4c7a5010f6e5). https://buildbot.python.org/all/#/builders/58/builds/2889 running: test_regrtest (32 min 8 sec) running: test_regrtest (32 min 38 sec) running: test_regrtest (33 min 8 sec) running: test_regrtest (33 min 38 sec) running: test_regrtest (34 min 8 sec) running: test_regrtest (34 min 38 sec) 1:19:18 load avg: 1.19 [419/419/1] test_regrtest crashed (Exit code 1) Timeout (0:35:00)! Thread 0x00000ddc (most recent call first): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\subprocess.py", line 1353 in _readerthread File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 876 in run File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 938 in _bootstrap_inner File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 896 in _bootstrap Thread 0x00000e68 (most recent call first): File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 1033 in _wait_for_tstate_lock File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\threading.py", line 1017 in join File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\subprocess.py", line 1382 in _communicate File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\subprocess.py", line 1015 in communicate File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\subprocess.py", line 491 in run File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_regrtest.py", line 504 in run_command File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_regrtest.py", line 529 in run_python File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_regrtest.py", line 680 in run_tests File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_regrtest.py", line 1178 in test_multiprocessing_timeout File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 611 in _callTestMethod File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 654 in run File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 714 in __call__ File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__ File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__ File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__ File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1996 in _run_suite File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 2092 in run_unittest File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 209 in _test_module File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 234 in _runtest_inner2 File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 270 in _runtest_inner File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 140 in _runtest File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 193 in runtest File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest_mp.py", line 66 in run_tests_worker File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 642 in _main File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 628 in main File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 695 in main File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 43 in _main File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 47 in File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code == Tests result: FAILURE == ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 06:24:01 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 10:24:01 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566383041.88.0.168742806977.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: > x86 Windows7 3.x > https://buildbot.python.org/all/#/builders/58/builds/2889 This buildbot looks slow: the 3 latest builds (2886, 2887, 2888) took around 1 hour. Example: 10 slowest tests: - test_multiprocessing_spawn: 15 min 31 sec - test_zipfile: 8 min 45 sec - test_concurrent_futures: 6 min 32 sec - test_pickle: 4 min 7 sec - test_regrtest: 3 min 47 sec - test_lzma: 3 min 13 sec - test_tarfile: 3 min 9 sec - test_capi: 2 min 54 sec - test_asyncio: 2 min 49 sec - test_venv: 1 min 57 sec Total duration: 1 hour 4 min ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 06:51:02 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 10:51:02 +0000 Subject: [issue30413] Add fnmatch.filterfalse function In-Reply-To: <1495286342.86.0.934515673373.issue30413@psf.upfronthosting.co.za> Message-ID: <1566384662.12.0.729036973025.issue30413@roundup.psfhosted.org> STINNER Victor added the comment: Rather than adding a new function, why not adding a parameter like sort(key=func, reverse=True)? Something like fnmatch.filterfalse(pat, invert=True)? The Unix grep command has a --invert-match option: -v, --invert-match Invert the sense of matching, to select non-matching lines. The Unix find and test commands use "!" to invert a condition. Example: find ! -name "*.py" # list files which doesn't match ".py" test ! -e setup.py # true if setup.py doesn't exist ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 06:53:08 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 10:53:08 +0000 Subject: [issue37901] 21 tests fail when run on an IPv6-only host In-Reply-To: <1566340883.47.0.899841913634.issue37901@roundup.psfhosted.org> Message-ID: <1566384788.55.0.903748522539.issue37901@roundup.psfhosted.org> STINNER Victor added the comment: > (I already filed separate issues about 5 other tests that hang rather than fail) Maybe use this issue as a meta-issue for IPv6-only issues? I saw: * bpo-37895: test_logging hangs on an IPv6-only host * bpo-37896: test_multiprocessing_fork hangs on an IPv6-only host * bpo-37897: test_asyncio hangs on an IPv6-only host * bpo-37898: test_httpservers hangs on an IPv6-only host * bpo-37899: test_xmlrpc hangs on an IPv6-only host ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 06:55:14 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 10:55:14 +0000 Subject: [issue37873] unittest: execute tests in parallel In-Reply-To: <1565964928.02.0.804836557192.issue37873@roundup.psfhosted.org> Message-ID: <1566384914.83.0.77236735978.issue37873@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 06:56:07 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 10:56:07 +0000 Subject: [issue25299] argparse: TypeError: __init__() takes at least 4 arguments (4 given) In-Reply-To: <1443785146.27.0.85852377889.issue25299@psf.upfronthosting.co.za> Message-ID: <1566384967.14.0.716653921334.issue25299@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: TypeError: __init__() takes at least 4 arguments (4 given) -> argparse: TypeError: __init__() takes at least 4 arguments (4 given) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 06:57:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 10:57:39 +0000 Subject: [issue36670] test suite broken due to cpu usage feature on win 10/ german In-Reply-To: <1555689157.38.0.435665423105.issue36670@roundup.psfhosted.org> Message-ID: <1566385059.25.0.0965122356184.issue36670@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 06:58:51 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 10:58:51 +0000 Subject: [issue36670] regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german) In-Reply-To: <1555689157.38.0.435665423105.issue36670@roundup.psfhosted.org> Message-ID: <1566385131.51.0.0568088612149.issue36670@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: test suite broken due to cpu usage feature on win 10/ german -> regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:06:13 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 11:06:13 +0000 Subject: [issue37790] subprocess.Popen() is extremely slow In-Reply-To: <1565210160.36.0.538688157223.issue37790@roundup.psfhosted.org> Message-ID: <1566385573.7.0.378915129859.issue37790@roundup.psfhosted.org> STINNER Victor added the comment: This issue lacks a lot of information: * What is your operating system (name and version)? On Linux, what is your Linux kernel version? * Which Python version did you try? * Which command are you running? * Do you use a shell? * Do you use bytes (default) or Unicode (universal_newlines=True or text=True)? * Can you provide a minimum reproducer? I don't know how to use msg349894: cmd is not defined. Attached 1.py uses 2 commands, appararently both use a shell: * "find /usr/bin -type f 2>/dev/null" * "objdump '%s'" "objdump '%s'" is unsafe and can lead to shell injection: try to avoid the usage of a shell. Use subprocess.Popen directly, or an helper which doesn't use shell=True. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:07:31 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 11:07:31 +0000 Subject: [issue37872] Move _Py_IDENTIFIER statics in Python/import.c to top of the file In-Reply-To: <1565961670.68.0.815730473417.issue37872@roundup.psfhosted.org> Message-ID: <1566385651.99.0.143091586651.issue37872@roundup.psfhosted.org> STINNER Victor added the comment: Why should we move static variables as globals? What is the rationale? _Py_IDENTIFIER uses a linked list internally to be able to free all these strings at Python exit. ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:09:28 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 11:09:28 +0000 Subject: =?utf-8?q?=5Bissue37871=5D_40_*_473_grid_of_=22=C3=A9=22_has_a_single_wro?= =?utf-8?q?ng_character_on_Windows?= In-Reply-To: <1565915764.5.0.613301280158.issue37871@roundup.psfhosted.org> Message-ID: <1566385768.68.0.520325055527.issue37871@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:10:00 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 11:10:00 +0000 Subject: [issue37871] Windows: WindowsConsoleIO produces mojibake for strings longer than 32 KiB In-Reply-To: <1565915764.5.0.613301280158.issue37871@roundup.psfhosted.org> Message-ID: <1566385800.0.0.965671478305.issue37871@roundup.psfhosted.org> Change by STINNER Victor : ---------- title: 40 * 473 grid of "?" has a single wrong character on Windows -> Windows: WindowsConsoleIO produces mojibake for strings longer than 32 KiB _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:10:34 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 11:10:34 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1566385834.85.0.917912289882.issue29535@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:10:49 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Wed, 21 Aug 2019 11:10:49 +0000 Subject: [issue30413] Add fnmatch.filterfalse function In-Reply-To: <1566384662.12.0.729036973025.issue30413@roundup.psfhosted.org> Message-ID: <20190821111040.GU16011@ando.pearwood.info> Steven D'Aprano added the comment: On Wed, Aug 21, 2019 at 10:51:02AM +0000, STINNER Victor wrote: > Rather than adding a new function, why not adding a parameter like > sort(key=func, reverse=True)? Something like fnmatch.filterfalse(pat, > invert=True)? Guido argues that as a general rule of thumb, we should avoid "constant bool parameters" and prefer seperate functions. For example, we have - re.search and re.match, not re.search(start=True) - str.find and str.rfind, not str.find(end=False) If we typically call the function with a bool constant: filter(pat, invert=True) rather than a variable or expression filter(pat, invert=condition or default) that's a hint that the two cases probably should be seperate functions. Martin Fowler agrees: https://martinfowler.com/bliki/FlagArgument.html as does Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20060828-18/?p=29953 (Of course there are cases where it is impractical to avoid bool flags -- if a function would otherwise take four flags, we would need sixteen functions! -- or there may be other reasons why we might go against that design rule.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:13:42 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 11:13:42 +0000 Subject: [issue37823] Telnet documentation: fix the link to open() In-Reply-To: <1565540009.68.0.907395311638.issue37823@roundup.psfhosted.org> Message-ID: <1566386022.63.0.100779469701.issue37823@roundup.psfhosted.org> STINNER Victor added the comment: New changeset e0b6117e2723327d6741d0aa599408514add5b30 by Victor Stinner (Michael Anckaert) in branch 'master': bpo-37823: Fix open() link in telnetlib doc (GH-15281) https://github.com/python/cpython/commit/e0b6117e2723327d6741d0aa599408514add5b30 ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:14:02 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 11:14:02 +0000 Subject: [issue37823] Telnet documentation: fix the link to open() In-Reply-To: <1565540009.68.0.907395311638.issue37823@roundup.psfhosted.org> Message-ID: <1566386042.93.0.0361810963182.issue37823@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15067 pull_request: https://github.com/python/cpython/pull/15355 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:14:08 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 11:14:08 +0000 Subject: [issue37823] Telnet documentation: fix the link to open() In-Reply-To: <1565540009.68.0.907395311638.issue37823@roundup.psfhosted.org> Message-ID: <1566386048.9.0.95422833579.issue37823@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15068 pull_request: https://github.com/python/cpython/pull/15356 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:28:42 2019 From: report at bugs.python.org (Lawrence R. Normie) Date: Wed, 21 Aug 2019 11:28:42 +0000 Subject: [issue37904] Suggested edit to Python Tutorial - Section 4 Message-ID: <1566386922.03.0.919785821856.issue37904@roundup.psfhosted.org> New submission from Lawrence R. Normie : Suggest amending the text of the first sentence in Section 4, from: "Besides the while statement just introduced, Python knows the usual control flow statements known from other languages, with some twists." to: Besides the while statement just introduced, Python follows the usual syntax fir control flow statements known from other languages, with some twists." ---------- assignee: docs at python components: Documentation messages: 350068 nosy: docs at python, lrnormie at gmail.com priority: normal severity: normal status: open title: Suggested edit to Python Tutorial - Section 4 type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:34:08 2019 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 21 Aug 2019 11:34:08 +0000 Subject: [issue37904] Suggested edit to Python Tutorial - Section 4 In-Reply-To: <1566386922.03.0.919785821856.issue37904@roundup.psfhosted.org> Message-ID: <1566387248.13.0.634540724362.issue37904@roundup.psfhosted.org> Eric V. Smith added the comment: I think I'd prefer "... Python uses the usual flow control statements known from other languages ..." It's not just syntax, after all. ---------- keywords: +newcomer friendly nosy: +eric.smith stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:38:08 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 11:38:08 +0000 Subject: [issue37823] Telnet documentation: fix the link to open() In-Reply-To: <1565540009.68.0.907395311638.issue37823@roundup.psfhosted.org> Message-ID: <1566387488.17.0.0302042865612.issue37823@roundup.psfhosted.org> miss-islington added the comment: New changeset c777dec6f47ce649f3dea88d308e36e45538fdac by Miss Islington (bot) in branch '3.8': bpo-37823: Fix open() link in telnetlib doc (GH-15281) https://github.com/python/cpython/commit/c777dec6f47ce649f3dea88d308e36e45538fdac ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:38:28 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 11:38:28 +0000 Subject: [issue37823] Telnet documentation: fix the link to open() In-Reply-To: <1565540009.68.0.907395311638.issue37823@roundup.psfhosted.org> Message-ID: <1566387508.72.0.255146585143.issue37823@roundup.psfhosted.org> miss-islington added the comment: New changeset 72088d56247ee422d8abeef94a89be463737b982 by Miss Islington (bot) in branch '3.7': bpo-37823: Fix open() link in telnetlib doc (GH-15281) https://github.com/python/cpython/commit/72088d56247ee422d8abeef94a89be463737b982 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:39:19 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 11:39:19 +0000 Subject: [issue37823] Telnet documentation: fix the link to open() In-Reply-To: <1565540009.68.0.907395311638.issue37823@roundup.psfhosted.org> Message-ID: <1566387559.42.0.0209437461088.issue37823@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15069 pull_request: https://github.com/python/cpython/pull/15357 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:52:08 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 11:52:08 +0000 Subject: [issue37823] Telnet documentation: fix the link to open() In-Reply-To: <1565540009.68.0.907395311638.issue37823@roundup.psfhosted.org> Message-ID: <1566388328.59.0.996110245012.issue37823@roundup.psfhosted.org> miss-islington added the comment: New changeset 98b11e1160a1749bfdb48bbf4c0dda177296b005 by Miss Islington (bot) in branch '2.7': bpo-37823: Fix open() link in telnetlib doc (GH-15281) https://github.com/python/cpython/commit/98b11e1160a1749bfdb48bbf4c0dda177296b005 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:53:30 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 11:53:30 +0000 Subject: [issue37823] Telnet documentation: fix the link to open() In-Reply-To: <1565540009.68.0.907395311638.issue37823@roundup.psfhosted.org> Message-ID: <1566388410.04.0.542658057867.issue37823@roundup.psfhosted.org> STINNER Victor added the comment: Thanks Michael Anckaert, I merged your PR and backported it to 2.7, 3.7 and 3.8 branches. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 07:55:16 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 11:55:16 +0000 Subject: [issue37851] faulthandler: only allocate the signal handler stack when faulthandler is used In-Reply-To: <1565790240.15.0.788753710363.issue37851@roundup.psfhosted.org> Message-ID: <1566388516.79.0.0682652769787.issue37851@roundup.psfhosted.org> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +15070 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15358 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 08:13:50 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 12:13:50 +0000 Subject: [issue37433] syntax error in multiline f-string produces ~40k spaces output In-Reply-To: <1561659761.86.0.416757939602.issue37433@roundup.psfhosted.org> Message-ID: <1566389630.11.0.192574238219.issue37433@roundup.psfhosted.org> STINNER Victor added the comment: The initial issue has been fixed in master by the commit 5b94f3578c662d5f1ee90c0e6b81481d9ec82d89: commit 5b94f3578c662d5f1ee90c0e6b81481d9ec82d89 Author: Anthony Sottile Date: Mon Jul 29 06:59:13 2019 -0700 Fix `SyntaxError` indicator printing too many spaces for multi-line strings (GH-14433) Backport to 3.8: commit cf52bd0b9b1c1b7ecdd91e1ebebd15ae5c213a2c. Thanks Anthony Sottile! I close the issue. -- If there is a different issue in Python 3.7 and you consider that it must be fixed, please file a new issue. Python 3.5 and 3.6 don't accept bugfixes anymore: https://devguide.python.org/#status-of-python-branches ---------- nosy: +vstinner resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 08:14:29 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 12:14:29 +0000 Subject: [issue37603] parsetok(): Assertion `(intptr_t)(int)(a - line_start) == (a - line_start)' failed, when running get-pip.py In-Reply-To: <1563270741.47.0.416934432776.issue37603@roundup.psfhosted.org> Message-ID: <1566389669.05.0.391625532956.issue37603@roundup.psfhosted.org> STINNER Victor added the comment: This issue is a duplicate of bpo-37433 which has been fixed. ---------- priority: release blocker -> resolution: -> fixed stage: patch review -> resolved status: open -> closed superseder: -> syntax error in multiline f-string produces ~40k spaces output _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 08:23:23 2019 From: report at bugs.python.org (Michael Anckaert) Date: Wed, 21 Aug 2019 12:23:23 +0000 Subject: [issue19820] docs are missing info about module attributes In-Reply-To: <1385620941.03.0.287546381963.issue19820@psf.upfronthosting.co.za> Message-ID: <1566390203.38.0.257326156685.issue19820@roundup.psfhosted.org> Change by Michael Anckaert : ---------- keywords: +patch pull_requests: +15071 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15359 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 08:38:54 2019 From: report at bugs.python.org (Christoph Deil) Date: Wed, 21 Aug 2019 12:38:54 +0000 Subject: [issue37905] Remove NormalDist.overlap() or improve documentation? Message-ID: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> New submission from Christoph Deil : I saw that Python 3.8 will add a NormalDist class: https://docs.python.org/3.8/library/statistics.html#normaldist-objects Personally I don't see the value of adding this to the Python standard lib. The natural progression would be to extend and extend, but in the end only duplicate what already exists in scientific Python packages. But Ok, I guess this is not up for debate any more? I'd like to make a specific comment on NormalDist.overlap. The rest of NormalDist is very standard, but that method is an oddball. My suggestion is to remove it or to improve the documentation. Current docstring: https://github.com/python/cpython/blob/44f2c096804e8e3adc09400a59ef9c9ae843f339/Lib/statistics.py#L959-L991 And this docs example: https://github.com/python/cpython/commit/318d537daabf2bd5f781255c7e25bfce260cf227#diff-d436928bc44b5d7c40a8047840f55d35R620-R629 > What percentage of men and women will have the same height in `two normally distributed populations with known means and standard deviations `_? 50.3% This statement doesn't make sense to me. No two people have the exact same height, I think the answer to this question should be 0%. Using n = 100_000; sum(m > w for m, w in zip(men.samples(n), women.samples(n))) / n I see that for 82% of random (men, women) matches the man will be larger. That's another measure, but still, stating that 50% of men and women have the same height is confusing. Note that there is a multitude of PDF overlap measures different from this min(pdf1, pdf2) that I think are much more common in statistics and the physical sciences: - https://en.wikipedia.org/wiki/Hellinger_distance - https://arxiv.org/pdf/1407.7172.pdf And note that the references that are given currently are weird (basic statistics textbooks would be appropriate references IMO, or open references like Wikipedia) - slides: http://www.iceaaonline.com/ready/wp-content/uploads/2014/06/MM-9-Presentation-Meet-the-Overlapping-Coefficient-A-Measure-for-Elevator-Speeches.pdf - implementation code comment points to http://dx.doi.org/10.1080/03610928908830127 which is behind a paywall Why add this one overlap measure and expose it under the "overlap" method name? My suggestion would be to be conservative and to remove that method again, before releasing it in 3.8. A reference in the docs could be added to other existing third-party codes (e.g. scipy or the uncertainties package) with further functionality, such as being able to handle correlations or multi-dimensional distributions. For this change I'd be happy to send a PR any time. Raymond and others interested in this topic - thoughts? (note: I wrote a MultiNorm class prototype last year at https://github.com/cdeil/multinorm/blob/master/multinorm.py and now wanted to rewrite it and try to find a good API and thus was interested in this NormalDist class and what functionality it offers) ---------- components: Library (Lib) messages: 350076 nosy: Christoph.Deil, rhettinger priority: normal severity: normal status: open title: Remove NormalDist.overlap() or improve documentation? type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 08:41:04 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 12:41:04 +0000 Subject: [issue37851] faulthandler: only allocate the signal handler stack when faulthandler is used In-Reply-To: <1565790240.15.0.788753710363.issue37851@roundup.psfhosted.org> Message-ID: <1566391264.79.0.703495820329.issue37851@roundup.psfhosted.org> STINNER Victor added the comment: New changeset d8c5adf6f83024238545aac0bb465289cc2dde84 by Victor Stinner in branch 'master': bpo-37851: faulthandler allocates its stack on demand (GH-15358) https://github.com/python/cpython/commit/d8c5adf6f83024238545aac0bb465289cc2dde84 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 08:41:58 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 12:41:58 +0000 Subject: [issue37851] faulthandler: only allocate the signal handler stack when faulthandler is used In-Reply-To: <1565790240.15.0.788753710363.issue37851@roundup.psfhosted.org> Message-ID: <1566391318.57.0.844032860873.issue37851@roundup.psfhosted.org> STINNER Victor added the comment: Note: faulthandler stack size is 16 KiB on my Fedora Linux 30 x86-64. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 08:44:00 2019 From: report at bugs.python.org (Zackery Spytz) Date: Wed, 21 Aug 2019 12:44:00 +0000 Subject: [issue37886] PyStructSequence_UnnamedField not exported In-Reply-To: <1566218629.27.0.381481574182.issue37886@roundup.psfhosted.org> Message-ID: <1566391440.13.0.505426846401.issue37886@roundup.psfhosted.org> Change by Zackery Spytz : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 08:44:41 2019 From: report at bugs.python.org (Zackery Spytz) Date: Wed, 21 Aug 2019 12:44:41 +0000 Subject: [issue37633] Py_CompileString and PyParser_SimpleParseString not exported in python38.dll In-Reply-To: <1563568606.34.0.923231546212.issue37633@roundup.psfhosted.org> Message-ID: <1566391481.86.0.221039106407.issue37633@roundup.psfhosted.org> Change by Zackery Spytz : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 08:45:09 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 21 Aug 2019 12:45:09 +0000 Subject: [issue37873] unittest: execute tests in parallel In-Reply-To: <1565964928.02.0.804836557192.issue37873@roundup.psfhosted.org> Message-ID: <1566391509.27.0.745556396371.issue37873@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 08:45:23 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 12:45:23 +0000 Subject: [issue37906] FreeBSD: test_threading: test_recursion_limit() crash with SIGSEGV and create a coredump Message-ID: <1566391523.37.0.328762522638.issue37906@roundup.psfhosted.org> New submission from STINNER Victor : On my FreeBSD 12.0-RELEASE-p10 VM, test_threading.test_recursion_limit() does crash with SIGSEGV and create a coredump. vstinner at freebsd$ ./python -m test -v test_threading -m test_recursion_limit == CPython 3.9.0a0 (heads/master:e0b6117e27, Aug 21 2019, 12:23:28) [Clang 6.0.1 (tags/RELEASE_601/final 335540)] == FreeBSD-12.0-RELEASE-p10-amd64-64bit-ELF little-endian == cwd: /usr/home/vstinner/python/master/build/test_python_3547 == CPU count: 2 == encodings: locale=UTF-8, FS=utf-8 Run tests sequentially 0:00:01 load avg: 4.85 [1/1] test_threading test_recursion_limit (test.test_threading.ThreadingExceptionTests) ... FAIL ====================================================================== FAIL: test_recursion_limit (test.test_threading.ThreadingExceptionTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/vstinner/python/master/Lib/test/test_threading.py", line 1086, in test_recursion_limit self.assertEqual(p.returncode, 0, "Unexpected error: " + stderr.decode()) AssertionError: -11 != 0 : Unexpected error: ---------------------------------------------------------------------- Ran 1 test in 6.017s FAILED (failures=1) Warning -- files was modified by test_threading Before: [] After: ['python.core'] test test_threading failed test_threading failed == Tests result: FAILURE == 1 test failed: test_threading Total duration: 7 sec 284 ms Tests result: FAILURE ---------- components: Tests messages: 350079 nosy: vstinner priority: normal severity: normal status: open title: FreeBSD: test_threading: test_recursion_limit() crash with SIGSEGV and create a coredump versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 08:55:16 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 21 Aug 2019 12:55:16 +0000 Subject: [issue37873] unittest: execute tests in parallel In-Reply-To: <1565964928.02.0.804836557192.issue37873@roundup.psfhosted.org> Message-ID: <1566392116.91.0.504160336304.issue37873@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: See also https://mail.python.org/pipermail/python-ideas/2017-September/047100.html . One of the ideas in the thread was to move test.regrtest parallel execution functionality into unittest. I think this would be good to have it in unittest like support in pytest for -j. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 09:03:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 13:03:39 +0000 Subject: [issue37906] FreeBSD: test_threading: test_recursion_limit() crash with SIGSEGV and create a coredump In-Reply-To: <1566391523.37.0.328762522638.issue37906@roundup.psfhosted.org> Message-ID: <1566392619.4.0.0385527379158.issue37906@roundup.psfhosted.org> STINNER Victor added the comment: I used git bisect in the 3.8 branch and I found this change: commit 8399641c34d8136c3151fda6461cc4727a20b28e Author: Miss Islington (bot) <31488909+miss-islington at users.noreply.github.com> Date: Thu Aug 1 07:38:57 2019 -0700 bpo-18049: Sync thread stack size to main thread size on macOS (GH-14748) This changeset increases the default size of the stack for threads on macOS to the size of the stack of the main thread and reenables the relevant recursion test. (cherry picked from commit 1a057bab0f18d6ad843ce321d1d77a4819497ae4) Co-authored-by: Ronald Oussoren Before this change, the test was skipped on FreeBSD: ... test_recursion_limit (test.test_threading.ThreadingExceptionTests) ... skipped 'test macosx problem' ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 09:06:16 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 13:06:16 +0000 Subject: [issue37906] FreeBSD: test_threading: test_recursion_limit() crash with SIGSEGV and create a coredump In-Reply-To: <1566391523.37.0.328762522638.issue37906@roundup.psfhosted.org> Message-ID: <1566392776.04.0.65915593541.issue37906@roundup.psfhosted.org> STINNER Victor added the comment: The crash start to occur with a Python callstack depth larger than 750. It doesn't crash with setrecursionlimit(750). See attached stack.py. Example: vstinner at freebsd$ ./python stack.py 750 10240 setrecursionlimit(750) stack_size: 10240.0 kiB = 10.0 MiB end of main thread It seems like calling _thread.stack_size(s) doesn't help: vstinner at freebsd$ ./python stack.py 1000 10240 setrecursionlimit(1000) stack_size: 10240.0 kiB = 10.0 MiB Segmentation fault (core dumped) -- I see different options: * Reduce the Python recursion limit in the test * Find a way to increase the default thread stack size on FreeBSD * Skip the test on FreeBSD On macOS, configure.ac uses a stack of 8 MiB: # Issue #18075: the default maximum stack size (8MBytes) is too # small for the default recursion limit. Increase the stack size # to ensure that tests don't crash # Note: This matches the value of THREAD_STACK_SIZE in # thread_pthread.h LINKFORSHARED="-Wl,-stack_size,1000000 $LINKFORSHARED" ---------- Added file: https://bugs.python.org/file48553/stack.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 09:06:38 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 13:06:38 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1566392798.62.0.19742753584.issue18049@roundup.psfhosted.org> STINNER Victor added the comment: The test does now crash on FreeBSD: see bpo-37906. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 09:08:50 2019 From: report at bugs.python.org (Carol Willing) Date: Wed, 21 Aug 2019 13:08:50 +0000 Subject: [issue37860] Add netlify deploy preview for docs In-Reply-To: <1565817286.53.0.142673590989.issue37860@roundup.psfhosted.org> Message-ID: <1566392930.45.0.973491828974.issue37860@roundup.psfhosted.org> Carol Willing added the comment: New changeset 87bc3b7a0b0c41ea5da2aa137c4145f437a1c9fd by Carol Willing (Ashwin Ramaswami) in branch 'master': bpo-37860: Add netlify deploy preview for docs (GH-15288) https://github.com/python/cpython/commit/87bc3b7a0b0c41ea5da2aa137c4145f437a1c9fd ---------- nosy: +willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 09:12:59 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 13:12:59 +0000 Subject: [issue37906] FreeBSD: test_threading: test_recursion_limit() crash with SIGSEGV and create a coredump In-Reply-To: <1566391523.37.0.328762522638.issue37906@roundup.psfhosted.org> Message-ID: <1566393179.26.0.881790236597.issue37906@roundup.psfhosted.org> STINNER Victor added the comment: Oh, my script called _thread.stack_size() to read the stack size, but that doesn't work: calling _thread.stack_size() sets the stack size to 0 again. stack2.py is the fixed script. It seems like the test works with a stack of 8 MiB and the default recursion limit of 1000 Python frames: vstinner at freebsd$ ./python stack.py 1000 4096 setrecursionlimit(1000) stack_size: 4096.0 kiB = 4.0 MiB Segmentation fault (core dumped) vstinner at freebsd$ ./python stack.py 1000 8192 setrecursionlimit(1000) stack_size: 8192.0 kiB = 8.0 MiB end of main thread So the problem is that the FreeBSD default thread stack size is too small. ---------- Added file: https://bugs.python.org/file48554/stack2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 09:26:33 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 13:26:33 +0000 Subject: [issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores. In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org> Message-ID: <1566393993.8.0.461886380871.issue37751@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 20f59fe1f7748ae899aceee4cb560e5e1f528a1f by Victor Stinner (Jordon Xu) in branch 'master': bpo-37751: Fix codecs.lookup() normalization (GH-15092) https://github.com/python/cpython/commit/20f59fe1f7748ae899aceee4cb560e5e1f528a1f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 09:27:23 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 13:27:23 +0000 Subject: [issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores. In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org> Message-ID: <1566394043.71.0.0523536948816.issue37751@roundup.psfhosted.org> STINNER Victor added the comment: Thanks for the fix Jordon Xu. IMHO this change is not strictly a bugfix, but more like an enhancement. I close the issue. If you consider that a backport to Python 3.7 and 3.8 is needed, please say so. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 10:00:06 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 21 Aug 2019 14:00:06 +0000 Subject: [issue37905] Remove NormalDist.overlap() or improve documentation? In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566396006.5.0.533349355576.issue37905@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 10:04:16 2019 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 21 Aug 2019 14:04:16 +0000 Subject: [issue37905] Remove NormalDist.overlap() or improve documentation? In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566396256.28.0.154223876391.issue37905@roundup.psfhosted.org> Change by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 10:44:10 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 21 Aug 2019 14:44:10 +0000 Subject: [issue37906] FreeBSD: test_threading: test_recursion_limit() crash with SIGSEGV and create a coredump In-Reply-To: <1566391523.37.0.328762522638.issue37906@roundup.psfhosted.org> Message-ID: <1566398650.25.0.364561322822.issue37906@roundup.psfhosted.org> Ronald Oussoren added the comment: I'd increase the default stack size for FreeBSD as well. AFAIK FreeBSD uses clang as the default compiler like macOS, and it is therefore likely that the two platforms have similar stack usage for similar code. BTW. I can provide a PR for this but cannot easily test on FreeBSD. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 11:15:38 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 21 Aug 2019 15:15:38 +0000 Subject: [issue37906] FreeBSD: test_threading: test_recursion_limit() crash with SIGSEGV and create a coredump In-Reply-To: <1566391523.37.0.328762522638.issue37906@roundup.psfhosted.org> Message-ID: <1566400538.93.0.47534800727.issue37906@roundup.psfhosted.org> STINNER Victor added the comment: On my FreeBSD 12.0 VM, /usr/bin/ld is a symbolic link to ld.ldd: it's the LLVM linker called "LLD": https://lld.llvm.org/ I modified manually Makefile to give 16 MiB stack to the main thread using: LINKFORSHARED= -Wl,--export-dynamic "-Wl,-z" "-Wl,stack-size=0x1000000" I added manually the following to Python/thread_pthread.h to give 16 MiB stack to thread: #undef THREAD_STACK_SIZE #define THREAD_STACK_SIZE 0x1000000 Using that, the RecurisionError is raised at a depth of 1000 Python function calls: before we exhaust the C stack. -- The syntax used in configure.ac doesn't work with LLD. I get such error: cc -pthread -Wl,--export-dynamic -Wl,-stack_size,1000000 -o Programs/_testembed Programs/_testembed.o libpython3.9d.a -lcrypt -ldl -lutil -lm -lm /usr/bin/ld: error: cannot open 1000000: No such file or directory ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 11:19:32 2019 From: report at bugs.python.org (George Zhang) Date: Wed, 21 Aug 2019 15:19:32 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566400772.91.0.816856697472.issue37902@roundup.psfhosted.org> Change by George Zhang : ---------- keywords: +patch pull_requests: +15072 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15360 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 12:01:18 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 21 Aug 2019 16:01:18 +0000 Subject: [issue30413] Add fnmatch.filterfalse function In-Reply-To: <1495286342.86.0.934515673373.issue30413@psf.upfronthosting.co.za> Message-ID: <1566403278.31.0.322106778128.issue30413@roundup.psfhosted.org> Raymond Hettinger added the comment: > Rather than adding a new function, why not adding a parameter Guido, the reason iteratools has a separate filter() and filterfalse() tools is because of your API guidance to prefer separate functions rather than having flags in most cases. Do you still feel that way and does it apply here? Personally, I would want to have a separate function for fnmatch.filter_false() rather than adding complexity to the API for fnmatch. ---------- nosy: +gvanrossum, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 12:17:42 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Wed, 21 Aug 2019 16:17:42 +0000 Subject: [issue37907] speed-up PyLong_As*() for large longs Message-ID: <1566404262.5.0.0996699211051.issue37907@roundup.psfhosted.org> New submission from Sergey Fedoseev : PyLong_As*() functions computes result for large longs like this: size_t x, prev; x = 0; while (--i >= 0) { prev = x; x = (x << PyLong_SHIFT) | v->ob_digit[i]; if ((x >> PyLong_SHIFT) != prev) { *overflow = sign; goto exit; } } It can be rewritten like this: size_t x = 0; while (--i >= 0) { if (x > (size_t)-1 >> PyLong_SHIFT) { goto overflow; } x = (x << PyLong_SHIFT) | v->ob_digit[i]; } This provides some speed-up: PyLong_AsSsize_t() $ python -m perf timeit -s "from struct import Struct; N = 1000; pack = Struct('n'*N).pack; values = (2**30,)*N" "pack(*values)" --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 9.69 us +- 0.02 us /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 8.61 us +- 0.07 us Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 9.69 us +- 0.02 us -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 8.61 us +- 0.07 us: 1.12x faster (-11%) PyLong_AsSize_t() $ python -m perf timeit -s "from struct import Struct; N = 1000; pack = Struct('N'*N).pack; values = (2**30,)*N" "pack(*values)" --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 10.5 us +- 0.1 us /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 8.19 us +- 0.17 us Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 10.5 us +- 0.1 us -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 8.19 us +- 0.17 us: 1.29x faster (-22%) PyLong_AsLong() $ python -m perf timeit -s "from struct import Struct; N = 1000; pack = Struct('l'*N).pack; values = (2**30,)*N" "pack(*values)" --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 9.68 us +- 0.02 us /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 8.48 us +- 0.22 us Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 9.68 us +- 0.02 us -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 8.48 us +- 0.22 us: 1.14x faster (-12%) PyLong_AsUnsignedLong() $ python -m perf timeit -s "from struct import Struct; N = 1000; pack = Struct('L'*N).pack; values = (2**30,)*N" "pack(*values)" --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 10.5 us +- 0.1 us /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 8.41 us +- 0.26 us Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 10.5 us +- 0.1 us -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 8.41 us +- 0.26 us: 1.25x faster (-20%) The mentioned pattern is also used in PyLong_AsLongLongAndOverflow(), but I left it untouched since the proposed change doesn't seem to affect its performance. ---------- components: Interpreter Core messages: 350091 nosy: sir-sigurd priority: normal severity: normal status: open title: speed-up PyLong_As*() for large longs type: performance versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 12:22:10 2019 From: report at bugs.python.org (hai shi) Date: Wed, 21 Aug 2019 16:22:10 +0000 Subject: [issue9938] Documentation for argparse interactive use In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za> Message-ID: <1566404530.42.0.57689457353.issue9938@roundup.psfhosted.org> Change by hai shi : ---------- pull_requests: +15073 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15362 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 12:22:49 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Wed, 21 Aug 2019 16:22:49 +0000 Subject: [issue37907] speed-up PyLong_As*() for large longs In-Reply-To: <1566404262.5.0.0996699211051.issue37907@roundup.psfhosted.org> Message-ID: <1566404569.59.0.306370296488.issue37907@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- keywords: +patch pull_requests: +15074 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15363 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 12:27:18 2019 From: report at bugs.python.org (hai shi) Date: Wed, 21 Aug 2019 16:27:18 +0000 Subject: [issue9938] Improving interactive use of argparse In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za> Message-ID: <1566404838.43.0.003460670114.issue9938@roundup.psfhosted.org> hai shi added the comment: It is a good idea. So I update this title and add PR 15362. I am not sure there have a problem of xuanli's CLA or not~ ---------- components: -Documentation nosy: +shihai1991 title: Documentation for argparse interactive use -> Improving interactive use of argparse versions: +Python 3.9 -Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 12:32:16 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 21 Aug 2019 16:32:16 +0000 Subject: [issue30413] Add fnmatch.filterfalse function In-Reply-To: <1495286342.86.0.934515673373.issue30413@psf.upfronthosting.co.za> Message-ID: <1566405136.42.0.346371746572.issue30413@roundup.psfhosted.org> Guido van Rossum added the comment: Yes, I still feel like this and I find it applies here. (Note that the module already has two variants of fnmatch(), so it's nothing new in this context.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 12:32:30 2019 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 21 Aug 2019 16:32:30 +0000 Subject: [issue30413] Add fnmatch.filterfalse function In-Reply-To: <1495286342.86.0.934515673373.issue30413@psf.upfronthosting.co.za> Message-ID: <1566405150.5.0.402955997248.issue30413@roundup.psfhosted.org> Change by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 12:36:38 2019 From: report at bugs.python.org (Christoph Deil) Date: Wed, 21 Aug 2019 16:36:38 +0000 Subject: [issue37905] Remove NormalDist.overlap() or improve documentation? In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566405398.61.0.865137090876.issue37905@roundup.psfhosted.org> Christoph Deil added the comment: The Monte Carlo example here has completely unstable results: https://github.com/python/cpython/commit/cc353a0cd95d9b0c93ed0b60ba762427a94c790d#diff-d436928bc44b5d7c40a8047840f55d35R633 If you run it multiple times, you will see that `mean` is relatively stable, but `stddev` varies from 10 to 50 to 100. The reason is that in the model there's a division by z, and the z distribution used has values arbitrarily close to zero: >>> NormalDist(5, 1.25).cdf(0) * 100_000 3.16 Suggest to change to a MC sampling example that isn't as pathological, doesn't involve division by zero. E.g. change the mean of z to 50, or reduce the stddev to 0.125 or some such change in parameters. Usually in stats or machine learning books and docs e.g. on statsmodels or scikit-learn etc., for methods where random numbers are involved, the seed is always set to a fixed value, to have reproducible results & docs. Suggest to make that change also here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 12:44:49 2019 From: report at bugs.python.org (George Zhang) Date: Wed, 21 Aug 2019 16:44:49 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566405889.17.0.230037476707.issue37902@roundup.psfhosted.org> George Zhang added the comment: I looked at the code for scrolling and moved it over to the ScrolledCanvas and TreeNode (because it uses a Label that sits on the canvas, meaning we have to rebind it here). I haven't figured out how to add the scroll-by-pressing-down-and-moving way but I'll look further into it. About the factoring out part, the ScrolledCanvas and TreeNode are both used by the two browsers, meaning that no code has to be added to them. In the future, a factory function could be made that when called with a canvas, it returns an event callback function that can be bound to the canvas. When called, it scrolls depending on the event type and other info. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 12:45:40 2019 From: report at bugs.python.org (Brett Cannon) Date: Wed, 21 Aug 2019 16:45:40 +0000 Subject: [issue37890] Modernize several tests in test_importlib In-Reply-To: <1566269296.72.0.828504709815.issue37890@roundup.psfhosted.org> Message-ID: <1566405940.8.0.690898810005.issue37890@roundup.psfhosted.org> Brett Cannon added the comment: A key question here is why are you trying to avoid the AttributeError case so much? If something has a bug and an attribute doesn't exist that should then that's a bug and the test needs to catch that. Now whether that's via an error from AttributeError being raise or an explicit failure case you still get notified, but there's a reason that we don't have attribute existence tests before every single attribute access throughout the test suite. ;) Basically unless the attribute is dynamic and thus you're explicitly testing the attribute got set then don't worry about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 13:04:18 2019 From: report at bugs.python.org (hai shi) Date: Wed, 21 Aug 2019 17:04:18 +0000 Subject: [issue37775] update doc of compileall In-Reply-To: <1565113080.48.0.890450145581.issue37775@roundup.psfhosted.org> Message-ID: <1566407058.6.0.430722963224.issue37775@roundup.psfhosted.org> Change by hai shi : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 13:05:22 2019 From: report at bugs.python.org (hai shi) Date: Wed, 21 Aug 2019 17:05:22 +0000 Subject: [issue37750] PyBuffer_FromContiguous not documented In-Reply-To: <1564822618.55.0.397769114373.issue37750@roundup.psfhosted.org> Message-ID: <1566407122.91.0.389654018383.issue37750@roundup.psfhosted.org> Change by hai shi : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 13:05:20 2019 From: report at bugs.python.org (hai shi) Date: Wed, 21 Aug 2019 17:05:20 +0000 Subject: [issue37698] Update doc of PyBuffer_ToContiguous In-Reply-To: <1564334680.0.0.401210106575.issue37698@roundup.psfhosted.org> Message-ID: <1566407120.5.0.513717985226.issue37698@roundup.psfhosted.org> Change by hai shi : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 13:11:33 2019 From: report at bugs.python.org (hai shi) Date: Wed, 21 Aug 2019 17:11:33 +0000 Subject: [issue37908] Add some examples of ArgumentParser.exit() Message-ID: <1566407493.49.0.869927821626.issue37908@roundup.psfhosted.org> New submission from hai shi : As paul said in bpo 9938: The exit and error methods are mentioned in the 3.4 documentation, but there are no examples of modifying them. 16.4.5.9. Exiting methods ArgumentParser.exit(status=0, message=None) ArgumentParser.error(message) I will update the examples in this weekend. ---------- assignee: docs at python components: Documentation messages: 350097 nosy: docs at python, shihai1991 priority: normal severity: normal status: open title: Add some examples of ArgumentParser.exit() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 13:12:09 2019 From: report at bugs.python.org (hai shi) Date: Wed, 21 Aug 2019 17:12:09 +0000 Subject: [issue37908] Add some examples of ArgumentParser.exit() In-Reply-To: <1566407493.49.0.869927821626.issue37908@roundup.psfhosted.org> Message-ID: <1566407529.39.0.234600781466.issue37908@roundup.psfhosted.org> hai shi added the comment: issue 9938 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 13:12:48 2019 From: report at bugs.python.org (hai shi) Date: Wed, 21 Aug 2019 17:12:48 +0000 Subject: [issue37908] Add some examples of ArgumentParser.exit() In-Reply-To: <1566407493.49.0.869927821626.issue37908@roundup.psfhosted.org> Message-ID: <1566407568.37.0.632912314257.issue37908@roundup.psfhosted.org> Change by hai shi : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 13:14:54 2019 From: report at bugs.python.org (Kyle Stanley) Date: Wed, 21 Aug 2019 17:14:54 +0000 Subject: [issue37890] Modernize several tests in test_importlib In-Reply-To: <1566269296.72.0.828504709815.issue37890@roundup.psfhosted.org> Message-ID: <1566407694.18.0.103882814525.issue37890@roundup.psfhosted.org> Kyle Stanley added the comment: > A key question here is why are you trying to avoid the AttributeError case so much? > but there's a reason that we don't have attribute existence tests before every single attribute access throughout the test suite Hmm, good point. I may have been fixating on avoiding exceptions within the tests a bit too much, perhaps the exception would be appropriate in this case. > Basically unless the attribute is dynamic and thus you're explicitly testing the attribute got set then don't worry about it. Ah, that answers my earlier question, thanks. (: With an initial glance, do you have any specific ideas as to how test_pkg_import.py should be changed to utilize importlib directly? I've been reading through the docs looking for ideas, but I'll admit that I'm not particularly experienced with using importlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 13:17:36 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 21 Aug 2019 17:17:36 +0000 Subject: [issue37905] Remove NormalDist.overlap() or improve documentation? In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566407856.1.0.855347036203.issue37905@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 13:39:40 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 21 Aug 2019 17:39:40 +0000 Subject: [issue37905] Remove NormalDist.overlap() or improve documentation? In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566409180.0.0.177150548315.issue37905@roundup.psfhosted.org> Raymond Hettinger added the comment: Several thoughts: * OVL was used often in the finance firm where I worked. * It provides a simple, easy to understand point estimate of the similarity or overlap between two PDFs. * It was far easier to use than a Students-t test to answer the question of how similar two normal distributions are and it is more precise than the more common technique of just running overlapping plots and doing it by eye. * It isn't easy for end-users to do this themselves without running an integration. * It is well defined and well motivated: See: "The overlapping coefficient as a measure of agreement between probability distributions and point estimation of the overlap of two normal densities" -- Henry F. Inman and Edwin L. Bradley Jr http://dx.doi.org/10.1080/03610928908830127 See also: https://www.rasch.org/rmt/rmt101r.htm And: http://www.iceaaonline.com/ready/wp-content/uploads/2014/06/MM-9-Presentation-Meet-the-Overlapping-Coefficient-A-Measure-for-Elevator-Speeches.pdf Perhaps, the wording can be improved on the male/female height example. Measured to finite precision, perhaps to the nearest centimeter, there will be overlaps. This is same kind of binning done with chi-square tests to compare how well two distributions match. AFAICT, this tool is well-defined, tested, and has legitimate use cases that are easy to achieve in other ways using only standard library tools. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 14:19:36 2019 From: report at bugs.python.org (sushma) Date: Wed, 21 Aug 2019 18:19:36 +0000 Subject: [issue36858] f-string '=' debugging output needs to be documented In-Reply-To: <1557347816.05.0.714667733239.issue36858@roundup.psfhosted.org> Message-ID: <1566411576.06.0.460236804963.issue36858@roundup.psfhosted.org> sushma added the comment: Hello, I'd like to work on this and will take a look. ---------- nosy: +syadlapalli _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 15:02:54 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 19:02:54 +0000 Subject: [issue37810] ndiff reports incorrect location when diff strings contain tabs In-Reply-To: <1565463544.19.0.692436897534.issue37810@roundup.psfhosted.org> Message-ID: <1566414174.7.0.88508448247.issue37810@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15075 pull_request: https://github.com/python/cpython/pull/15365 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 15:24:49 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 21 Aug 2019 19:24:49 +0000 Subject: [issue22964] dbm.open(..., "x") In-Reply-To: <1417214551.97.0.349316203885.issue22964@psf.upfronthosting.co.za> Message-ID: <1566415489.66.0.332797577009.issue22964@roundup.psfhosted.org> Serhiy Storchaka added the comment: Agree with Batuhan. There are three dbm implementations in the stdlib: dumb, ndbm and gnu. It may be possible to implement the "x" flag in the former two, but gdbm_open() does not support it. Since by default the implementation is chosen automatically in dbm.open(), I do not think it is practically to implement a flag which do not work with all implementations. ---------- nosy: +serhiy.storchaka resolution: -> rejected stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 15:28:52 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 21 Aug 2019 19:28:52 +0000 Subject: [issue20410] Argument Clinic: add 'self' return converter In-Reply-To: <1390847418.07.0.605398644696.issue20410@psf.upfronthosting.co.za> Message-ID: <1566415732.68.0.129630796071.issue20410@roundup.psfhosted.org> Serhiy Storchaka added the comment: Batuhan, argument converters and return converters are different things. I have no opinion about the idea itself. You can try, Zachary, and see whether it makes the code clearer. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 15:34:55 2019 From: report at bugs.python.org (George Zhang) Date: Wed, 21 Aug 2019 19:34:55 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566416095.57.0.281074203031.issue37902@roundup.psfhosted.org> Change by George Zhang : ---------- pull_requests: -15072 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 15:42:29 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 21 Aug 2019 19:42:29 +0000 Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules In-Reply-To: <1553040840.44.0.769944520222.issue36375@roundup.psfhosted.org> Message-ID: <1566416549.08.0.646412309099.issue36375@roundup.psfhosted.org> Change by Greg Price : ---------- nosy: +Greg Price _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 15:45:07 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 21 Aug 2019 19:45:07 +0000 Subject: [issue37905] Remove NormalDist.overlap() or improve documentation? In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566416707.57.0.283730955014.issue37905@roundup.psfhosted.org> Raymond Hettinger added the comment: BTW, I get your concern about the statistics module as a whole. From the point of view of an expert numpy/scipy user, the whole module seems pointless. However, the purpose of the module is to put a useful subset of statistical tools into the hands of everyday Python users who aren't part of that numeric ecosystem (think of the same people who use MS Excel as part of this group). The module doesn't require extra pip installation, an Anaconda distribution, or even knowledge of array broadcasting and whatnot. For the past few months, I've been user testing the new components of the statistics module and have had good success. Some of the examples in the docs were born from those interactions. I also get your concern about what is usually found in statistics textbooks; however, those books tend to cover a wide range of distributions, include proofs, and heavily weight hypothesis testing. Typically, little space is given to descriptive statistics, q-q plots, or other things that are handy in day-to-day practice. The NormalDist class encapsulates a lot of knowledge that is easily forgotten (that variances are additive, how to translate and rescale), or that a constant divided by a normal distribution doesn't give another normal distribution. I've tried this out on otherwise not mathematically inclined users and they've found it to be useful and intuitive. In contrast, the scipy ecosystem presumes much more sophistication. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 15:45:29 2019 From: report at bugs.python.org (George Zhang) Date: Wed, 21 Aug 2019 19:45:29 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566416729.9.0.893503709015.issue37902@roundup.psfhosted.org> Change by George Zhang : ---------- pull_requests: +15076, 15077 pull_request: https://github.com/python/cpython/pull/15360 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 15:45:29 2019 From: report at bugs.python.org (George Zhang) Date: Wed, 21 Aug 2019 19:45:29 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566416729.8.0.60621248605.issue37902@roundup.psfhosted.org> Change by George Zhang : ---------- pull_requests: +15076 pull_request: https://github.com/python/cpython/pull/15360 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 15:52:16 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 21 Aug 2019 19:52:16 +0000 Subject: [issue37905] Improve docs for NormalDist.overlap() In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566417136.58.0.587047016082.issue37905@roundup.psfhosted.org> Raymond Hettinger added the comment: > Raymond and others interested in this topic - thoughts? Please do submit a PR with an improved example for the MonteCarlo simulation. I'm not fond of that example at all. It should be as short as possible while getting the core idea across. But it should be something that doesn't have a simple analytic solution so as to motivate the concept. Go ahead and use a fixed numeric seed as well. ---------- components: +Documentation -Library (Lib) title: Remove NormalDist.overlap() or improve documentation? -> Improve docs for NormalDist.overlap() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 16:08:51 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 20:08:51 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566418131.32.0.222415082656.issue37834@roundup.psfhosted.org> Steve Dower added the comment: So my colleagues confirmed that they deliberately represent junction points as symlinks within WSL, including translating the target to the mounted location (assuming it is mounted) and letting the Linux code traverse it normally. They also said they haven't heard any feedback suggesting it causes any trouble. However, the more I've thought about the implications of islink() returning true for a junction, the more I've come around to Eryk's point of view, so I'm going to merge this as is (the PR currently only sets S_IFLNK for actual symlinks). That said, nt.readlink() will still be able to read the target of a junction, and code like I have in PR 15287 that uses readlink() to follow links will resolve them (noting that that implementation of realpath() attempts to let the OS follow it first). I think that covers the intended use cases best. The only updates left are a couple of docs here, but I'll finish up issue9949 first and rebase on those changes as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 16:14:30 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 21 Aug 2019 20:14:30 +0000 Subject: [issue37905] Improve docs for NormalDist In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566418470.96.0.904835525129.issue37905@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- title: Improve docs for NormalDist.overlap() -> Improve docs for NormalDist _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 16:26:10 2019 From: report at bugs.python.org (Tim Peters) Date: Wed, 21 Aug 2019 20:26:10 +0000 Subject: [issue37810] ndiff reports incorrect location when diff strings contain tabs In-Reply-To: <1565463544.19.0.692436897534.issue37810@roundup.psfhosted.org> Message-ID: <1566419170.23.0.894629725082.issue37810@roundup.psfhosted.org> Change by Tim Peters : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 16:34:59 2019 From: report at bugs.python.org (George Zhang) Date: Wed, 21 Aug 2019 20:34:59 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566419699.83.0.24809957949.issue37902@roundup.psfhosted.org> Change by George Zhang : ---------- pull_requests: -15076 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 16:35:05 2019 From: report at bugs.python.org (George Zhang) Date: Wed, 21 Aug 2019 20:35:05 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566419705.23.0.348180563621.issue37902@roundup.psfhosted.org> Change by George Zhang : ---------- pull_requests: -15077 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 16:43:09 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 20:43:09 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566420189.23.0.101595962508.issue9949@roundup.psfhosted.org> Steve Dower added the comment: New changeset 75e064962ee0e31ec19a8081e9d9cc957baf6415 by Steve Dower in branch 'master': bpo-9949: Enable symlink traversal for ntpath.realpath (GH-15287) https://github.com/python/cpython/commit/75e064962ee0e31ec19a8081e9d9cc957baf6415 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 16:43:21 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 20:43:21 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566420201.9.0.202683420171.issue9949@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15078 pull_request: https://github.com/python/cpython/pull/15367 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 16:55:03 2019 From: report at bugs.python.org (Tianshu Gao) Date: Wed, 21 Aug 2019 20:55:03 +0000 Subject: [issue37909] Thread pool return ref hold memory Message-ID: <1566420903.63.0.857548145971.issue37909@roundup.psfhosted.org> New submission from Tianshu Gao : This is very similar to issue35715. But this is happen for thread. After the func in thread finished, the memory is still hold and accumulate. import asyncio import time import concurrent import threading loop = asyncio.get_event_loop() def prepare_a_giant_list(): m = [] for i in range(1000*1000): m.append("There's a fat fox jump over a sheep" + str(i)) th_num = threading.active_count() print("Thread number is {}".format(th_num)) return m @asyncio.coroutine def main(): global loop global counter async_executor = concurrent.futures.ThreadPoolExecutor(max_workers=20) loop.run_in_executor(async_executor, prepare_a_giant_list) time.sleep(15) loop.run_in_executor(async_executor, prepare_a_giant_list) time.sleep(15) loop.run_in_executor(async_executor, prepare_a_giant_list) time.sleep(15) loop.run_in_executor(async_executor, prepare_a_giant_list) time.sleep(15) if __name__ == "__main__": loop.run_until_complete(main()) loop.close() ---------- components: asyncio messages: 350108 nosy: Tianshu Gao, asvetlov, yselivanov priority: normal severity: normal status: open title: Thread pool return ref hold memory type: resource usage versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 16:58:40 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 21 Aug 2019 20:58:40 +0000 Subject: [issue37909] Thread pool return ref hold memory In-Reply-To: <1566420903.63.0.857548145971.issue37909@roundup.psfhosted.org> Message-ID: <1566421120.79.0.966319632759.issue37909@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 17:09:36 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 21:09:36 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566421776.95.0.923714894777.issue9949@roundup.psfhosted.org> miss-islington added the comment: New changeset c30c869e8dec5eefdee7977943ffa11a8e3c8d75 by Miss Islington (bot) in branch '3.8': bpo-9949: Enable symlink traversal for ntpath.realpath (GH-15287) https://github.com/python/cpython/commit/c30c869e8dec5eefdee7977943ffa11a8e3c8d75 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 17:11:58 2019 From: report at bugs.python.org (George Zhang) Date: Wed, 21 Aug 2019 21:11:58 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566421918.57.0.897594098746.issue37902@roundup.psfhosted.org> Change by George Zhang : ---------- pull_requests: +15079 pull_request: https://github.com/python/cpython/pull/15368 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 17:16:56 2019 From: report at bugs.python.org (George Zhang) Date: Wed, 21 Aug 2019 21:16:56 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566422216.01.0.840252347904.issue37902@roundup.psfhosted.org> George Zhang added the comment: Looks like my PRs are getting out of hand... This is the final PR :P ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 17:32:08 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Wed, 21 Aug 2019 21:32:08 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566423128.85.0.396282419033.issue9949@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: There are multiple failures on several buildbots after commit 75e064962ee0e31ec19a8081e9d9cc957baf6415 was merged: BUILDBOT FAILURE REPORT ======================= Builder name: AMD64 Windows7 SP1 3.x Builder url: https://buildbot.python.org/all/#/builders/40/ Build url: https://buildbot.python.org/all/#/builders/40/builds/2886 Failed tests ------------ - test_realpath_curdir (test.test_ntpath.TestNtpath) - test_unicode_in_batch_file (test.test_venv.BasicTest) Test leaking resources ---------------------- Build summary ------------- == Tests result: FAILURE then FAILURE == 384 tests OK. 10 slowest tests: - test_multiprocessing_spawn: 2 min 45 sec - test_tools: 2 min 5 sec - test_distutils: 1 min 50 sec - test_tokenize: 1 min 41 sec - test_concurrent_futures: 1 min 39 sec - test_lib2to3: 1 min 14 sec - test_mmap: 1 min 11 sec - test_largefile: 1 min 8 sec - test_asyncio: 1 min 4 sec - test_io: 1 min 3 sec 2 tests failed: test_ntpath test_venv 33 tests skipped: test_curses test_dbm_gnu test_dbm_ndbm test_devpoll test_epoll test_fcntl test_fork1 test_gdb test_grp test_ioctl test_kqueue test_multiprocessing_fork test_multiprocessing_forkserver test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_readline test_resource test_spwd test_syslog test_threadsignals test_tix test_tk test_ttk_guionly test_wait3 test_wait4 test_xxtestfuzz test_zipfile64 2 re-run tests: test_ntpath test_venv Total duration: 13 min 17 sec Tracebacks ---------- ```traceback Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", line 337, in test_unicode_in_batch_file out, err = check_output( File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", line 42, in check_output raise subprocess.CalledProcessError( subprocess.CalledProcessError: Command '['\\\\?\\C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmpsbwlxx8h\\\u03fc\u045e\u0422\u03bb\u0424\u0419\\Scripts\\activate.bat', '&', 'python_d.exe', '-c', 'print(0)']' returned non-zero exit status 1. Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", line 337, in test_unicode_in_batch_file out, err = check_output( File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_venv.py", line 42, in check_output raise subprocess.CalledProcessError( subprocess.CalledProcessError: Command '['\\\\?\\C:\\Users\\Buildbot\\AppData\\Local\\Temp\\tmpxl3ubg90\\\u03fc\u045e\u0422\u03bb\u0424\u0419\\Scripts\\activate.bat', '&', 'python_d.exe', '-c', 'print(0)']' returned non-zero exit status 1. Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_ntpath.py", line 210, in test_realpath_curdir tester("ntpath.realpath('/'.join(['.'] * 100))", expected) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_ntpath.py", line 30, in tester raise TestFailed("%s should return: %s but returned: %s" \ ``` Current builder status ---------------------- The builder is failing currently Commits ------- - bcc446f525421156fe693139140e7051d000592e - 75e064962ee0e31ec19a8081e9d9cc957baf6415 Other builds with similar failures ---------------------------------- - https://buildbot.python.org/all/#/builders/208/builds/279 - https://buildbot.python.org/all/#/builders/12/builds/2985 - https://buildbot.python.org/all/#/builders/12/builds/2986 - https://buildbot.python.org/all/#/builders/219/builds/190 - https://buildbot.python.org/all/#/builders/40/builds/2885 - https://buildbot.python.org/all/#/builders/3/builds/3298 - https://buildbot.python.org/all/#/builders/3/builds/3299 Steve, can you take a look? ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 17:34:04 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 21:34:04 +0000 Subject: [issue31226] shutil.rmtree fails when target has an internal directory junction (Windows) In-Reply-To: <1502978298.87.0.60982184572.issue31226@psf.upfronthosting.co.za> Message-ID: <1566423244.17.0.370136913091.issue31226@roundup.psfhosted.org> Steve Dower added the comment: I think this definitely conflicts with the behaviour we've been working on for the last week over on issue37834 (the PR is going to conflict for sure). I am making a change to rmtree() that will cause it to delete junction point without trying to recursively remove their contents, which should avoid the listdir() that was failing here. That should be enough to cover the original issue. We also ended up settling on isdir/islink semantics for directory junctions that don't quite match those discussed here. I'm inclined to agree that we should figure out the best way to distinguish volume mounts from directory junctions, but that is going to be best layered on top of the other changes that I'm working on getting merged right now. The commit messages or doc changes in PR 15231 are the best place to see where we ended up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 17:38:40 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 21:38:40 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566423520.78.0.682212556153.issue9949@roundup.psfhosted.org> Change by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 17:38:52 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 21:38:52 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566423532.75.0.524830178652.issue9949@roundup.psfhosted.org> Change by Steve Dower : ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 17:41:50 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 21 Aug 2019 21:41:50 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566423710.97.0.0958941216283.issue37902@roundup.psfhosted.org> Terry J. Reedy added the comment: I won't merge with mousescroll duplicated, or worse, triplicated. If 'self.text/canvas' is replaced with 'event.widget', then the 'self' parameter can be deleted and the function made a standalone module function. For now, put it in tree, copied with the docstring from editor.py. Then import it into editor. (Reason: Avoid creating more import loops.) This will make mousescroll depend on IDLE not subclassing text/canvas and overriding yview_scroll. It currently does not and I expect it never will. But, to be safe, this should be added to the docstring, and tested (fairly simple) along with other added tests. The labels partially blocking the canvas bindings is nasty. Mousescroll is wrapped as a tk script for each label. I expect to eventually replace the labels and other visual tree stuff with a ttk.Treeview. Then no canvas wheel bindings will be needed. In anticipation of that, replace 'yview_scroll(' with the equivalent 'yview(SCROLL,' (Treeview only has the latter.) The resulting line will be event.widget.yview(SCROLL, lines, "units") For some reason, creating a module browser for pyshell takes 3 times as long with my repository 3.9 debug build as with my 3.8 installed normal build. (The ration is usually about 2.) But the patch with the extra bindings and wrappings does not make it much worse, if any. Scrolling by moving mouse while holding down middle mouse wheel seems to be built into Text. But I never/seldom use it and have not tried to add it to anything else. At least on Windows, it works differently than on Firefox. Text only moved with drag, which makes it jerky, not with distance from start position. And one cannot only scroll part of a large file, not to top and bottom. Notepad and notepad++ do not have it. So skip it for now. When one edits a branch and pushes commits to ones github fork, the changes appear on any existing PR. Closing a PR and reopening a new one is unusual and loses comments. Post to core-mentorship if you need help with git and our workflow. My PR-15360 comment applies to the current one. ---------- stage: patch review -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 17:47:00 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 21:47:00 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566424020.72.0.930882901172.issue9949@roundup.psfhosted.org> Steve Dower added the comment: On it ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 17:51:45 2019 From: report at bugs.python.org (Marco Sulla) Date: Wed, 21 Aug 2019 21:51:45 +0000 Subject: [issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity In-Reply-To: <1565258224.48.0.98423013878.issue37792@roundup.psfhosted.org> Message-ID: <1566424305.08.0.165891243743.issue37792@roundup.psfhosted.org> Marco Sulla added the comment: @scoder: 1. the fact that == does not traverse the Element is IMHO unpythonic and non-standard. A trivial example: >>> a = {1: {2: 3}} >>> b = {1: {2: 3}} >>> a == b True You can have a dictionary complicated as you want, but if they have the same structure, the two dictionaries will be always equals, even if their id are not. I think that no one could say to remove this dictionary feature and simply check the ids, leaving the deep comparison to the user, without raising a rebellion :) 2. the fact that SubElement seems a constructor is not an implementation detail. It's misleading and confusing, since a programmer expects that it will return an object of type SubElement, while there's no SubElement class. This is peculiar. I can be wrong, but I never encountered such a bizarre naming in the standard library. IMHO SubElement should be deprecated and it should call `subElement()`, a simply copy of the old SubElement 3. I'm not suggesting to remove fromstringlist and tostringlist, but that they could be deprecated and simply call fromstring and tostring, that should use duck typing for doing what fromstringlist and tostringlist did. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 17:56:48 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 21:56:48 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566424608.7.0.448577705156.issue9949@roundup.psfhosted.org> Steve Dower added the comment: I suspect the relevant failure here (which is not listed in Pablo's post) is this one: ====================================================================== ERROR: test_realpath_curdir (test.test_ntpath.TestNtpath) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_ntpath.py", line 210, in test_realpath_curdir tester("ntpath.realpath('/'.join(['.'] * 100))", expected) File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_ntpath.py", line 30, in tester raise TestFailed("%s should return: %s but returned: %s" \ test.support.TestFailed: ntpath.realpath('/'.join(['.'] * 100)) should return: C:\buildbot.python.org\3.x.kloth-win64\build\build\test_python_5340\test_python_worker_1408 but returned: \\?\C:\buildbot.python.org\3.x.kloth-win64\build\build\test_python_5340\test_python_worker_1408\.\.\.\.\.\.\.\.\.\.\.\.\.\.\.\. The path being normalized is longer than MAX_PATH, which is clearly causing failures with Windows APIs as implemented on Windows 7. I can add the normpath() call back in, which should remove all the dots before ever actually testing realpath() and get it back down under MAX_PATH. That won't help anyone using real long paths on Win7 though, but then again the only reason this test was passing before was because there was a normpath() call, so we're no worse off (apart from performance-wise). The venv issues seem unrelated. I'll get the realpath one fixed first and then take a look at those once I've finished today's tasks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 17:59:24 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 21:59:24 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566424764.09.0.552307191292.issue9949@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +15080 pull_request: https://github.com/python/cpython/pull/15369 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:08:19 2019 From: report at bugs.python.org (Sam Franklin) Date: Wed, 21 Aug 2019 22:08:19 +0000 Subject: [issue37910] argparse wrapping fails with metavar="" (no metavar) Message-ID: <1566425299.96.0.375120843288.issue37910@roundup.psfhosted.org> New submission from Sam Franklin : When argparse wraps the usage text, it can fail its assertion tests with whitespace differences. This can occur when metavar="", needed if a user wishes to avoid having a metavar print. It also could occur if a user specifies any other whitespace. Here's a minimum example (depending on $COLUMNS): import argparse # based on Vajrasky Kok's script in https://bugs.python.org/issue11874 parser = argparse.ArgumentParser(prog='PROG') parser.add_argument('--nil', metavar='', required=True) parser.add_argument('--a', metavar='a' * 165) parser.parse_args() This produces the AssertionError at the bottom of this comment. A solution is to have the two asserts ignore whitespace. I'll submit a pull request very shortly for this. (First time so happy for any comments or critiques!) A more extensive example: import argparse # based on Vajrasky Kok's script in https://bugs.python.org/issue11874 parser = argparse.ArgumentParser(prog='PROG') parser.add_argument('--nil', metavar='', required=True) parser.add_argument('--Line-Feed', metavar='\n', required=True) parser.add_argument('--Tab', metavar='\t', required=True) parser.add_argument('--Carriage-Return', metavar='\r', required=True) parser.add_argument('--Carriage-Return-and-Line-Feed', metavar='\r\n', required=True) parser.add_argument('--vLine-Tabulation', metavar='\v', required=True) parser.add_argument('--x0bLine-Tabulation', metavar='\x0b', required=True) parser.add_argument('--fForm-Feed', metavar='\f', required=True) parser.add_argument('--x0cForm-Feed', metavar='\x0c', required=True) parser.add_argument('--File-Separator', metavar='\x1c', required=True) parser.add_argument('--Group-Separator', metavar='\x1d', required=True) parser.add_argument('--Record-Separator', metavar='\x1e', required=True) parser.add_argument('--C1-Control-Code', metavar='\x85', required=True) parser.add_argument('--Line-Separator', metavar='\u2028', required=True) parser.add_argument('--Paragraph-Separator', metavar='\u2029', required=True) parser.add_argument('--a', metavar='a' * 165) parser.parse_args() This is related to https://bugs.python.org/issue17890 and https://bugs.python.org/issue32867. File "/minimum_argparse_bug.py", line 7, in parser.parse_args() File "/path/to/cpython/Lib/argparse.py", line 1758, in parse_args args, argv = self.parse_known_args(args, namespace) File "/path/to/cpython/Lib/argparse.py", line 1790, in parse_known_args namespace, args = self._parse_known_args(args, namespace) File "/path/to/cpython/Lib/argparse.py", line 1996, in _parse_known_args start_index = consume_optional(start_index) File "/path/to/cpython/Lib/argparse.py", line 1936, in consume_optional take_action(action, args, option_string) File "/path/to/cpython/Lib/argparse.py", line 1864, in take_action action(self, namespace, argument_values, option_string) File "/path/to/cpython/Lib/argparse.py", line 1037, in __call__ parser.print_help() File "/path/to/cpython/Lib/argparse.py", line 2483, in print_help self._print_message(self.format_help(), file) File "/path/to/cpython/Lib/argparse.py", line 2467, in format_help return formatter.format_help() File "/path/to/cpython/Lib/argparse.py", line 281, in format_help help = self._root_section.format_help() File "/path/to/cpython/Lib/argparse.py", line 212, in format_help item_help = join([func(*args) for func, args in self.items]) File "/path/to/cpython/Lib/argparse.py", line 212, in item_help = join([func(*args) for func, args in self.items]) File "/path/to/cpython/Lib/argparse.py", line 336, in _format_usage assert ' '.join(opt_parts) == opt_usage AssertionError ---------- components: Library (Lib) messages: 350117 nosy: sjfranklin priority: normal severity: normal status: open title: argparse wrapping fails with metavar="" (no metavar) type: crash versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:12:20 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 21 Aug 2019 22:12:20 +0000 Subject: [issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity In-Reply-To: <1565258224.48.0.98423013878.issue37792@roundup.psfhosted.org> Message-ID: <1566425540.89.0.362269439473.issue37792@roundup.psfhosted.org> Raymond Hettinger added the comment: Macro, we appreciate your sentiments. Please consider this module has been around for a long time and that others aren't reacting to the API the same way you are. Deprecating SubElement, fromstringlist() and tostringlist() because you don't like them will just cause disruption to existing, deployed code. You're about 15 years too late for a design discussion ;-) That ship has sailed. Your proposal to add a new feature for comparing elements is in the realm of the possible. That said, the other respondents made a reasonable case the different people would want to do it differently. Despite your insistence that only your way makes sense, we do have to consider other users as well. The other respondents provided you with other ways to meet your needs. Their disinclination to not add this feature is backed-up by years of experience with this module and with lxml. Communication note: Please do not go down of the path of making yourself the arbiter of what is Pythonic or standard. The other core devs in this conversation are highly experienced. Insulting them or the Fredrik Lundh's existing API won't help matters. We should add a clear note to the docs: "Comparing the string serialized XML should not be used to establish semantic equality. The preferred ways are to use C14N canonicalization or to write a tree walker where the notion of equivalence can be customized to include/exclude attribute order, to include/exclude comments or processing instructions, to include/exclude whitespace at non-leaf nodes". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:13:32 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 21 Aug 2019 22:13:32 +0000 Subject: [issue32949] Simplify "with"-related opcodes In-Reply-To: <1519566194.29.0.467229070634.issue32949@psf.upfronthosting.co.za> Message-ID: <1566425612.83.0.817953398001.issue32949@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- versions: +Python 3.9 -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:14:04 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 21 Aug 2019 22:14:04 +0000 Subject: [issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds In-Reply-To: <1491349378.03.0.0671954460373.issue29988@psf.upfronthosting.co.za> Message-ID: <1566425644.04.0.672023573595.issue29988@roundup.psfhosted.org> Change by Gregory P. Smith : ---------- versions: +Python 3.9 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:25:08 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 22:25:08 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566426308.8.0.323778185165.issue9949@roundup.psfhosted.org> Steve Dower added the comment: Okay, the venv break is related (and it should have broken more frequently). The new realpath() implementation leaves the \\?\ prefix behind if the path doesn't exist, since that's the error you get when the path is longer than MAX_PATH and you're on a system that can't handle it. I think the best fix is probably to strip the prefix if the file didn't exist at the start and still doesn't exist afterwards. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:25:43 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 22:25:43 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566426343.79.0.245732534488.issue9949@roundup.psfhosted.org> Steve Dower added the comment: And sorry, the test_ntpath traceback was half listed in Pablo's message, but was missing the critical lines :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:27:36 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 22:27:36 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566426456.36.0.399804008612.issue37834@roundup.psfhosted.org> Steve Dower added the comment: New changeset df2d4a6f3d5da2839c4fc11d31511c8e028daf2c by Steve Dower in branch 'master': bpo-37834: Normalise handling of reparse points on Windows (GH-15231) https://github.com/python/cpython/commit/df2d4a6f3d5da2839c4fc11d31511c8e028daf2c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:27:36 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 22:27:36 +0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows In-Reply-To: <1193054658.57.0.203252941268.issue1311@psf.upfronthosting.co.za> Message-ID: <1566426456.45.0.790824026967.issue1311@roundup.psfhosted.org> Steve Dower added the comment: New changeset df2d4a6f3d5da2839c4fc11d31511c8e028daf2c by Steve Dower in branch 'master': bpo-37834: Normalise handling of reparse points on Windows (GH-15231) https://github.com/python/cpython/commit/df2d4a6f3d5da2839c4fc11d31511c8e028daf2c ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:28:08 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 22:28:08 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566426488.4.0.157911330955.issue37834@roundup.psfhosted.org> Change by Steve Dower : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:28:13 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 21 Aug 2019 22:28:13 +0000 Subject: [issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds In-Reply-To: <1491349378.03.0.0671954460373.issue29988@psf.upfronthosting.co.za> Message-ID: <1566426493.6.0.176519062069.issue29988@roundup.psfhosted.org> Raymond Hettinger added the comment: Historically, in C, Python, and and low-level interrupt programming it was the responsibility of a person writing a signal handler to make minimal variable edits and not disrupt anything else in the ecosystem. Are we changing that rule? (I'm still at the cringing stage and possibly haven't evolved my views yet). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:31:04 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 22:31:04 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566426664.41.0.845542152349.issue37834@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +15081 stage: commit review -> patch review pull_request: https://github.com/python/cpython/pull/15370 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:31:04 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 22:31:04 +0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows In-Reply-To: <1193054658.57.0.203252941268.issue1311@psf.upfronthosting.co.za> Message-ID: <1566426664.52.0.523066652055.issue1311@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +15082 pull_request: https://github.com/python/cpython/pull/15370 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:34:28 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 22:34:28 +0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows In-Reply-To: <1193054658.57.0.203252941268.issue1311@psf.upfronthosting.co.za> Message-ID: <1566426868.7.0.143479444267.issue1311@roundup.psfhosted.org> Steve Dower added the comment: Well, I was trying not to resurrect this old issue, but looks like I did it accidentally. Hi there, old hands! We miss you :) We also figured out a new [l]stat() implementation on Windows that handles symlinks and junctions better, and also non-file types such as NUL. So I guess I'll mark this as resolved in Python 3.8 ---------- resolution: not a bug -> fixed stage: -> resolved versions: +Python 3.8, Python 3.9 -Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:52:45 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 22:52:45 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566427965.51.0.541128673901.issue37834@roundup.psfhosted.org> Steve Dower added the comment: New changeset 9eb3d5463976068900e94b860ced7e035885835c by Steve Dower in branch '3.8': bpo-37834: Normalise handling of reparse points on Windows (GH-15370) https://github.com/python/cpython/commit/9eb3d5463976068900e94b860ced7e035885835c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:52:45 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 22:52:45 +0000 Subject: [issue1311] os.path.exists(os.devnull) regression on windows In-Reply-To: <1193054658.57.0.203252941268.issue1311@psf.upfronthosting.co.za> Message-ID: <1566427965.59.0.938103563913.issue1311@roundup.psfhosted.org> Steve Dower added the comment: New changeset 9eb3d5463976068900e94b860ced7e035885835c by Steve Dower in branch '3.8': bpo-37834: Normalise handling of reparse points on Windows (GH-15370) https://github.com/python/cpython/commit/9eb3d5463976068900e94b860ced7e035885835c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 18:58:05 2019 From: report at bugs.python.org (Brett Cannon) Date: Wed, 21 Aug 2019 22:58:05 +0000 Subject: [issue37663] Making venv activation script prompts consistent In-Reply-To: <1563914466.51.0.723098783517.issue37663@roundup.psfhosted.org> Message-ID: <1566428285.15.0.957362045577.issue37663@roundup.psfhosted.org> Brett Cannon added the comment: New changeset 48ede6b8f685669f53d26ae8456647af42ae3dae by Brett Cannon in branch 'master': bpo-37663: have venv activation scripts all consistently use __VENV_PROMPT__ for prompt customization (GH-14941) https://github.com/python/cpython/commit/48ede6b8f685669f53d26ae8456647af42ae3dae ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:00:42 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 23:00:42 +0000 Subject: [issue37482] Email address display name fails with both encoded words and special chars In-Reply-To: <1562068275.57.0.247896906946.issue37482@roundup.psfhosted.org> Message-ID: <1566428442.49.0.396417624257.issue37482@roundup.psfhosted.org> miss-islington added the comment: New changeset df0c21ff46c5c37b6913828ef8c7651f523432f8 by Miss Islington (bot) (bsiem) in branch 'master': bpo-37482: Fix email address name with encoded words and special chars (GH-14561) https://github.com/python/cpython/commit/df0c21ff46c5c37b6913828ef8c7651f523432f8 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:00:53 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 23:00:53 +0000 Subject: [issue37482] Email address display name fails with both encoded words and special chars In-Reply-To: <1562068275.57.0.247896906946.issue37482@roundup.psfhosted.org> Message-ID: <1566428453.9.0.413678946905.issue37482@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15083 pull_request: https://github.com/python/cpython/pull/15371 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:01:15 2019 From: report at bugs.python.org (Semyon) Date: Wed, 21 Aug 2019 23:01:15 +0000 Subject: [issue37911] Minor error in PEP567 code example Message-ID: <1566428475.33.0.0889947555242.issue37911@roundup.psfhosted.org> New submission from Semyon : In PEP-567 there is a code example in `contextvars.Context` section (https://www.python.org/dev/peps/pep-0567/#contextvars-context): ``` # Print all context variables and their values in 'ctx': print(ctx.items()) ``` But `ctx.items()` doesn't return a list of tuples as probably expected by this code; instead it returns a `items` object which, unlike `dict_items`, does not contain any sensible `repr` or `str`. So this print statement will output something like ``. I think this code example should be chaned to something like `print(list(ctx.items()))`. ---------- assignee: docs at python components: Documentation messages: 350129 nosy: MarSoft, docs at python priority: normal severity: normal status: open title: Minor error in PEP567 code example versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:02:30 2019 From: report at bugs.python.org (Sam Franklin) Date: Wed, 21 Aug 2019 23:02:30 +0000 Subject: [issue37910] argparse wrapping fails with metavar="" (no metavar) In-Reply-To: <1566425299.96.0.375120843288.issue37910@roundup.psfhosted.org> Message-ID: <1566428550.63.0.552194043401.issue37910@roundup.psfhosted.org> Change by Sam Franklin : ---------- keywords: +patch pull_requests: +15084 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15372 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:21:52 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 23:21:52 +0000 Subject: [issue37482] Email address display name fails with both encoded words and special chars In-Reply-To: <1562068275.57.0.247896906946.issue37482@roundup.psfhosted.org> Message-ID: <1566429712.71.0.590126260903.issue37482@roundup.psfhosted.org> miss-islington added the comment: New changeset c5bba853d5e7836f6d4340e18721d3fb3a6ee0f7 by Miss Islington (bot) in branch '3.7': bpo-37482: Fix email address name with encoded words and special chars (GH-14561) https://github.com/python/cpython/commit/c5bba853d5e7836f6d4340e18721d3fb3a6ee0f7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:22:36 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 23:22:36 +0000 Subject: [issue36311] Flaw in Windows code page decoder for large input In-Reply-To: <1552723600.79.0.686719955113.issue36311@roundup.psfhosted.org> Message-ID: <1566429756.87.0.844944294525.issue36311@roundup.psfhosted.org> Steve Dower added the comment: New changeset 7ebdda0dbee7df6f0c945a7e1e623e47676e112d by Steve Dower in branch 'master': bpo-36311: Fixes decoding multibyte characters around chunk boundaries and improves decoding performance (GH-15083) https://github.com/python/cpython/commit/7ebdda0dbee7df6f0c945a7e1e623e47676e112d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:22:46 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 23:22:46 +0000 Subject: [issue36311] Flaw in Windows code page decoder for large input In-Reply-To: <1552723600.79.0.686719955113.issue36311@roundup.psfhosted.org> Message-ID: <1566429766.38.0.703002634119.issue36311@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15085 pull_request: https://github.com/python/cpython/pull/15374 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:22:52 2019 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 21 Aug 2019 23:22:52 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566429772.88.0.125034405224.issue37531@roundup.psfhosted.org> Jeremy Kloth added the comment: I happened to catch a stuck build prior to the process being killed: https://buildbot.python.org/all/#/builders//builds/2887 In short, the PR doesn't change the problem. The regrtest main will wait indefinitely on the successfully killed process. I have some ideas to try, but creating a reproducer is not exactly easy... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:22:53 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 23:22:53 +0000 Subject: [issue36311] Flaw in Windows code page decoder for large input In-Reply-To: <1552723600.79.0.686719955113.issue36311@roundup.psfhosted.org> Message-ID: <1566429773.71.0.0916860376617.issue36311@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15086 pull_request: https://github.com/python/cpython/pull/15375 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:29:04 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 23:29:04 +0000 Subject: [issue36311] Flaw in Windows code page decoder for large input In-Reply-To: <1552723600.79.0.686719955113.issue36311@roundup.psfhosted.org> Message-ID: <1566430144.93.0.457308594568.issue36311@roundup.psfhosted.org> Steve Dower added the comment: I'll get the 3.7 and 3.8 backports merged - looks like they're trivial. Going to need some help with the 2.7 backport, but I'm happy to approve a PR. ---------- stage: patch review -> backport needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:32:08 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 21 Aug 2019 23:32:08 +0000 Subject: [issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds In-Reply-To: <1491349378.03.0.0671954460373.issue29988@psf.upfronthosting.co.za> Message-ID: <1566430328.67.0.593457758293.issue29988@roundup.psfhosted.org> Gregory P. Smith added the comment: The signal handler in this case is CPython's internal signal handling system thus any such onus falls on us... The great signal handling hack of "set a flag that the interpreter loop checks on occasion" trick lasted a long time, but our VM has since evolved to be much more complicated than every bytecode being a safe interrupt point. FYI - Most of the in-room conversation we tried to capture on this issue thread was at the core dev sprint a couple years ago (Sept 2017). It'll similarly take me a while to swap this context back in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:45:05 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 23:45:05 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566431105.59.0.637629377612.issue9949@roundup.psfhosted.org> Steve Dower added the comment: New changeset 06be2c7f357d12249445e95def1fb708a087b357 by Steve Dower in branch 'master': bpo-9949: Call normpath() in realpath() and avoid unnecessary prefixes (GH-15369) https://github.com/python/cpython/commit/06be2c7f357d12249445e95def1fb708a087b357 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:46:46 2019 From: report at bugs.python.org (Steve Dower) Date: Wed, 21 Aug 2019 23:46:46 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566431206.48.0.931337387197.issue9949@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +15087 pull_request: https://github.com/python/cpython/pull/15376 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:53:59 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 23:53:59 +0000 Subject: [issue36311] Flaw in Windows code page decoder for large input In-Reply-To: <1552723600.79.0.686719955113.issue36311@roundup.psfhosted.org> Message-ID: <1566431639.31.0.765716625071.issue36311@roundup.psfhosted.org> miss-islington added the comment: New changeset f93c15aedc2ea2cb8b56fc9dbb0d412918992e86 by Miss Islington (bot) in branch '3.8': bpo-36311: Fixes decoding multibyte characters around chunk boundaries and improves decoding performance (GH-15083) https://github.com/python/cpython/commit/f93c15aedc2ea2cb8b56fc9dbb0d412918992e86 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 19:56:01 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 21 Aug 2019 23:56:01 +0000 Subject: [issue36311] Flaw in Windows code page decoder for large input In-Reply-To: <1552723600.79.0.686719955113.issue36311@roundup.psfhosted.org> Message-ID: <1566431761.84.0.887225411047.issue36311@roundup.psfhosted.org> miss-islington added the comment: New changeset 735a960ac98cf414caf910565220ab2761fa542a by Miss Islington (bot) in branch '3.7': bpo-36311: Fixes decoding multibyte characters around chunk boundaries and improves decoding performance (GH-15083) https://github.com/python/cpython/commit/735a960ac98cf414caf910565220ab2761fa542a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 20:00:00 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 22 Aug 2019 00:00:00 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566432000.46.0.251225212472.issue9949@roundup.psfhosted.org> Eryk Sun added the comment: I'm tentatively reopening this issue for you to consider the following point, Steve. A real path is not always the same as a final path. We can find code that does `relpath(realpath(target), realpath(start))` to compute the relative path to target for a symlink. The final path can't be relied on for this unless we always evaluate the symlink from the final path to `start`. In particular, it cannot be relied on if the relative path traverses a junction. What code like this needs from a realpath() implementation is a solid (real) path, not a final path. In other words, the caller wants a solidified form of `start` that can be used to compute the path to a target for a relative symlink, but one that works when accessed from `start`, not the final path of `start`. Generally this means resolving symlinks in the path, but not mount points. That's what Unix realpath() does, but of course there it's simpler because the only name surrogate in Unix is a symlink, which is never a mount point and never a directory. Here's an example. In this first case "scripts" is a junction mount point that targets "C:/spam/etc/scripts": >>> eggs = r'C:\spam\dlls\eggs.dll' >>> scripts = r'C:\spam\scripts' >>> rel_eggs_right = os.path.relpath(eggs, scripts) >>> print(rel_eggs_right) ..\dlls\eggs.dll >>> os.symlink(rel_eggs_right, 'C:/spam/scripts/eggs_right.dll') >>> os.path.exists('C:/spam/scripts/eggs_right.dll') True >>> scripts_final = os.path._getfinalpathname(scripts)[4:] >>> print(scripts_final) C:\spam\etc\scripts >>> rel_eggs_wrong = os.path.relpath(eggs, scripts_final) >>> print(rel_eggs_wrong) ..\..\dlls\eggs.dll >>> os.symlink(rel_eggs_wrong, 'C:/spam/scripts/eggs_wrong.dll') >>> os.path.exists('C:/spam/scripts/eggs_wrong.dll') False If we remove the junction and replace it with a 'soft' symlink that targets the same directory, then using the final path works, and using the given path no longer works. >>> print(os.readlink('C:/spam/scripts')) C:\spam\etc\scripts >>> scripts_final = os.path._getfinalpathname(scripts)[4:] >>> rel_eggs_right_2 = os.path.relpath(eggs, scripts_final) >>> print(rel_eggs_right_2) ..\..\dlls\eggs.dll >>> os.symlink(rel_eggs_right_2, 'C:/spam/scripts/eggs_right_2.dll') >>> os.path.exists('C:/spam/scripts/eggs_right_2.dll') True >>> rel_eggs_wrong_2 = os.path.relpath(eggs, scripts) >>> print(rel_eggs_wrong_2) ..\dlls\eggs.dll >>> os.symlink(rel_eggs_wrong_2, 'C:/spam/scripts/eggs_wrong_2.dll') >>> os.path.exists('C:/spam/scripts/eggs_wrong_2.dll') False When the kernel traverses "scripts" as a soft link, it collapses to the target (i.e. "C:/spam/etc/scripts"), so our relative path that was computed from the final path is right in this case. On the other hand, if "scripts" is is a mount point (junction), it's a hard (solid) component. It does not collapse to the target (the kernel even checks the junction's security descriptor, which it does not do for a symlink), so ".." in the relative symlink traverses the junction component as if it were an actual directory. What we need is an implementation of realpath("C:/spam/scripts") that returns "C:\\spam\\scripts" when "scripts" is a mount point and returns "C:\\spam\\etc\\scripts" when "scripts" is a symlink. This means we need an implementation of realpath() that looks a lot like posixpath.realpath. Generally a mount point should be walked over like a directory, just as mount points are handled in Unix. The difference is that a mount point in Windows is allowed to target a symlink. (This is a design flaw; Unix doesn't allow it.) Since we need to know the target of a junction, we have to read the reparse point, until we hit a real directory target. As long as it targets another junction, it remains a hard component. As soon as it targets a symlink, however, it becomes a soft component that needs to be resolved. If the junction targets a name surrogate reparse point that we can't read, then our only option is to get a final path. This is dysfunctional. We should raise an exception for this case. Code can handle the exception and knowingly get a final path instead of a real path. This also means we can't reliably compute a real path for a remote path (UNC) because we can't manually evaluate the target of a remote junction. A remote junction is meaningless to us. If we're evaluating a UNC path and reach a junction, we have to give up on a real path and settle for a final path. We can get a final path because that lets the kernel in the server talk to our kernel to resolve any combination of mount points (handled on the server side) and symlinks (handled on our side). This case should also raise an exception. Aware code can handle it by getting a real path and taking appropriate measures. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 20:17:50 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 22 Aug 2019 00:17:50 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566433070.57.0.364490555329.issue9949@roundup.psfhosted.org> Steve Dower added the comment: > We can find code that does `relpath(realpath(target), realpath(start))` to compute the relative path to target for a symlink. > In other words, the caller wants a solidified form of `start` that can be used to compute the path to a target for a relative symlink, but one that works when accessed from `start`, not the final path of `start`. I don't know how common this scenario is, but I can certainly say that it's never worked on Windows. You'd also end up with a relative symlink in a _real_ directory somewhere (that the junction was pointing at) that is unable to reach `target`, because it's now being resolved against the wrong start. Relative symlinks are nearly as evil as symlink loops :) Given there is no POSIX concept of a "final" path, a real path is the closest analogy. If this is the quality of edge case where that happens to break down, I'm okay with leaving it broken. (Similarly for the junction/symlink combination on remote systems. I don't see any way that POSIX emulation can properly support that, but it seems like the far more rare case - and I say this as someone whose employer *lives and breathes* unnecessarily complicated SMB shares ;) I've never seen this become an issue.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 20:23:41 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 22 Aug 2019 00:23:41 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566433421.62.0.502977241558.issue9949@roundup.psfhosted.org> Steve Dower added the comment: New changeset a50d2f7e199f3be60c70c1586ee60ec60bf36642 by Steve Dower in branch '3.8': bpo-9949: Call normpath() in realpath() and avoid unnecessary prefixes (GH-15376) https://github.com/python/cpython/commit/a50d2f7e199f3be60c70c1586ee60ec60bf36642 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 20:24:12 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 22 Aug 2019 00:24:12 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566433452.03.0.31833605275.issue37834@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +15088 pull_request: https://github.com/python/cpython/pull/15377 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 20:24:33 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 22 Aug 2019 00:24:33 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566433473.85.0.407353761171.issue37834@roundup.psfhosted.org> Steve Dower added the comment: Adding a small fix for the Win7 buildbots in PR 15377 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 20:33:33 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 22 Aug 2019 00:33:33 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566434012.99.0.422624146099.issue9949@roundup.psfhosted.org> Eryk Sun added the comment: > Aware code can handle it [the exception] by getting a real path and > taking appropriate measures. That should be "by getting a final path". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 20:34:07 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 22 Aug 2019 00:34:07 +0000 Subject: [issue37528] test_tarfile: test_extractall_symlinks() fails on Windows with: [WinError 206] The filename or extension is too long In-Reply-To: <1562672057.8.0.696699034391.issue37528@roundup.psfhosted.org> Message-ID: <1566434047.11.0.757259977504.issue37528@roundup.psfhosted.org> Steve Dower added the comment: I disabled the long path support on my own build and can reproduce this by passing a long path to --tempdir Unfortunately, I'm not familiar enough with what tarfile is trying to do here - why is it recreating the entire directory structure within itself? Browsing through lib/tarfile.py, I suspect it's the mix of "/" literals and os.path functions that's at fault here. It probably requires a much bigger job to go through and fix it up than simply fixing tests. ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 20:42:59 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 22 Aug 2019 00:42:59 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566434579.27.0.487409774335.issue37834@roundup.psfhosted.org> Steve Dower added the comment: New changeset 374be59b8e479afa8c7a8ae6e77e98915e2f6d45 by Steve Dower in branch 'master': bpo-37834: Fix test on Windows 7 (GH-15377) https://github.com/python/cpython/commit/374be59b8e479afa8c7a8ae6e77e98915e2f6d45 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 20:43:08 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 00:43:08 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566434588.0.0.850677985702.issue37834@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15089 pull_request: https://github.com/python/cpython/pull/15378 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 20:52:38 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 22 Aug 2019 00:52:38 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566435158.73.0.199644785307.issue9949@roundup.psfhosted.org> Eryk Sun added the comment: >> We can find code that does `relpath(realpath(target), >> realpath(start))` to compute the relative path to target >> for a symlink. >> ... > I don't know how common this scenario is, but I can certainly > say that it's never worked on Windows. You'd also end up with a > relative symlink in a _real_ directory somewhere (that the > junction was pointing at) that is unable to reach `target`, > because it's now being resolved against the wrong start. With ntpath.realpath == ntpath.abspath, it actually works fine for just junctions because in most cases a mount point in Windows should be handled simply as just a directory, not resolved as its target. Revisit my example. This is what I showed when "C:/spam/scripts" is a junction. It's only wrong if the junction targets a directory symlink -- a chimeric mount-point-link that NT has made the mistake of allowing. (The kernel developers should have known to disallow this when they introduced Unix-like symlinks. When evaluating a mount point that targets a symlink, or any name-surrogate reparse point, it should fail the call as an invalid reparse point. For simplicity and our sanity, a mount point should always have consistent semantics in path parsing as a hard component that behaves like a regular directory. Then we could *always* handle it as just a directory -- whether it's local or remote. They messed up badly, IMO.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 21:01:25 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 01:01:25 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566435685.63.0.57897464253.issue37834@roundup.psfhosted.org> miss-islington added the comment: New changeset 967d625a6df27fb490f035045ec8fe4675001d63 by Miss Islington (bot) in branch '3.8': bpo-37834: Fix test on Windows 7 (GH-15377) https://github.com/python/cpython/commit/967d625a6df27fb490f035045ec8fe4675001d63 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 21:02:04 2019 From: report at bugs.python.org (Seaky Lone) Date: Thu, 22 Aug 2019 01:02:04 +0000 Subject: [issue37912] fstring with quotation marks conflict Message-ID: <1566435724.71.0.382771248594.issue37912@roundup.psfhosted.org> New submission from Seaky Lone : For example, I have the following code: something = 'some thing' string = f'some text {something.split(' ')}' The second expression is thought to be invalid because it is regarded as two strings ['some text {something.split(', ')}']. I have to change either pair of '' to "" in order to make things work. I think this should not be an invalid expression because the ' ' or any other expressions inside the {} should be independent of the outer ''. ---------- components: Interpreter Core messages: 350147 nosy: Seaky Lone priority: normal severity: normal status: open title: fstring with quotation marks conflict versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 21:04:01 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 22 Aug 2019 01:04:01 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1566435841.13.0.299041998308.issue37834@roundup.psfhosted.org> Steve Dower added the comment: That should be all the buildbot issues fixes, so I'm marking this resolved and will wait for the inevitable 3.8.0b4 feedback! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 21:06:21 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 22 Aug 2019 01:06:21 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566435981.49.0.011931683179.issue9949@roundup.psfhosted.org> Steve Dower added the comment: At this point, I'm inclined to say let's wait and see what the 3.8.0b4 feedback looks like. Given that WSL has been fudging the boundaries here and hasn't suffered as a result, I don't expect much of a problem (and this change does actually make realpath() consistent between Windows native and WSL, which is nice). But I'm definitely open to making changes to this again if it turns out we need to. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 21:11:12 2019 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 22 Aug 2019 01:11:12 +0000 Subject: [issue37912] fstring with quotation marks conflict In-Reply-To: <1566435724.71.0.382771248594.issue37912@roundup.psfhosted.org> Message-ID: <1566436272.55.0.574553677964.issue37912@roundup.psfhosted.org> Eric V. Smith added the comment: The lexer sees an f-string: f'some text {something.split(' next to a normal string: ')}' The first of those is not a valid f-string because of the unmatched left brace, so it's an error. I'm contemplating making the f-string parser smarter to be able to detect this, but it's a long way off. For an explanation of why it works the way it does currently, see https://mail.python.org/archives/list/python-dev at python.org/message/BDZCXGRW5KTUOGMRT6OHH6S3UD4BV5ZV/ . This post also has an example similar to yours. ---------- assignee: -> eric.smith nosy: +eric.smith resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 21:34:49 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 22 Aug 2019 01:34:49 +0000 Subject: [issue37911] Minor error in PEP567 code example In-Reply-To: <1566428475.33.0.0889947555242.issue37911@roundup.psfhosted.org> Message-ID: <1566437689.94.0.734330759656.issue37911@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: PEPs have their own GitHub issue tracker though I am not sure of edits to this PEP. GitHub : https://github.com/python/peps/issues . This can be closed as third party. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 21:36:31 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 22 Aug 2019 01:36:31 +0000 Subject: [issue37910] argparse wrapping fails with metavar="" (no metavar) In-Reply-To: <1566425299.96.0.375120843288.issue37910@roundup.psfhosted.org> Message-ID: <1566437791.51.0.186897436155.issue37910@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 22:18:01 2019 From: report at bugs.python.org (Paulo Henrique Silva) Date: Thu, 22 Aug 2019 02:18:01 +0000 Subject: [issue36876] Global C variables are a problem. In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org> Message-ID: <1566440281.4.0.843757960803.issue36876@roundup.psfhosted.org> Change by Paulo Henrique Silva : ---------- nosy: +phsilva _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 22:24:54 2019 From: report at bugs.python.org (Paulo Henrique Silva) Date: Thu, 22 Aug 2019 02:24:54 +0000 Subject: [issue36854] GC operates out of global runtime state. In-Reply-To: <1557334825.47.0.818401533303.issue36854@roundup.psfhosted.org> Message-ID: <1566440694.16.0.716833495129.issue36854@roundup.psfhosted.org> Change by Paulo Henrique Silva : ---------- nosy: +phsilva _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 22:27:14 2019 From: report at bugs.python.org (Paulo Henrique Silva) Date: Thu, 22 Aug 2019 02:27:14 +0000 Subject: [issue24554] GC should happen when a subinterpreter is destroyed In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za> Message-ID: <1566440834.52.0.35492600992.issue24554@roundup.psfhosted.org> Change by Paulo Henrique Silva : ---------- nosy: +phsilva _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 22:41:25 2019 From: report at bugs.python.org (Kim Oldfield) Date: Thu, 22 Aug 2019 02:41:25 +0000 Subject: [issue37862] Search doesn't find built-in functions In-Reply-To: <1565831586.7.0.196033639625.issue37862@roundup.psfhosted.org> Message-ID: <1566441685.51.0.757510493583.issue37862@roundup.psfhosted.org> Kim Oldfield added the comment: Usually the search page is the quickest way to find documentation about a module or function - quicker than navigating through a couple of levels of pages (documentation home, index, index by letter, scroll or search in page to find desired name, click on name). Searching for builtin functions is inconsistent. Some functions (eg getattr) are found as expected in a search, while other functions (eg zip and many others) aren't found in the search results. This could easily lead someone to incorrectly concluding that the function they are search for doesn't exist in python. I find the response of "The search page is the last thing one should use" strange. Surely as the option to search is there, and it mostly works, we should be making incremental improvements as necessary to make it better so that everyone can easily find the right parts of the python documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 22:49:20 2019 From: report at bugs.python.org (Paulo Henrique Silva) Date: Thu, 22 Aug 2019 02:49:20 +0000 Subject: [issue36877] [meta] Move fields from _PyRuntimeState to PyInterpreterState. In-Reply-To: <1557515517.79.0.229526383765.issue36877@roundup.psfhosted.org> Message-ID: <1566442160.26.0.430719219408.issue36877@roundup.psfhosted.org> Change by Paulo Henrique Silva : ---------- nosy: +phsilva _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 22:51:15 2019 From: report at bugs.python.org (Ammar Askar) Date: Thu, 22 Aug 2019 02:51:15 +0000 Subject: [issue37862] Search doesn't find built-in functions In-Reply-To: <1565831586.7.0.196033639625.issue37862@roundup.psfhosted.org> Message-ID: <1566442275.27.0.685539228241.issue37862@roundup.psfhosted.org> Ammar Askar added the comment: See also https://bugs.python.org/issue34398 There is some related work done by Julien there as well: https://github.com/JulienPalard/pydocsearch ---------- nosy: +ammar2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 23:37:53 2019 From: report at bugs.python.org (Paulo Henrique Silva) Date: Thu, 22 Aug 2019 03:37:53 +0000 Subject: [issue36710] Pass _PyRuntimeState as an argument rather than using the _PyRuntime global variable In-Reply-To: <1556110680.79.0.127639989845.issue36710@roundup.psfhosted.org> Message-ID: <1566445073.9.0.363875032617.issue36710@roundup.psfhosted.org> Change by Paulo Henrique Silva : ---------- nosy: +phsilva _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 21 23:52:16 2019 From: report at bugs.python.org (Paulo Henrique Silva) Date: Thu, 22 Aug 2019 03:52:16 +0000 Subject: [issue34690] Store startup modules as C structures for 20%+ startup speed improvement In-Reply-To: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za> Message-ID: <1566445936.66.0.590917194286.issue34690@roundup.psfhosted.org> Change by Paulo Henrique Silva : ---------- nosy: +phsilva _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 00:41:10 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 22 Aug 2019 04:41:10 +0000 Subject: [issue37894] [win] shutil.which can not find the path if 'cmd' include directory path and not include extension name In-Reply-To: <1566316777.4.0.882745227499.issue37894@roundup.psfhosted.org> Message-ID: <1566448870.53.0.69326413572.issue37894@roundup.psfhosted.org> Eryk Sun added the comment: The code that sets up the PATHEXT `files` could be moved up. It also needs to be fixed in order to implement the correct behavior. For example: use_bytes = isinstance(cmd, bytes) files = [cmd] if _WINDOWS: # Also look for the name plus each PATHEXT extension. default_pathext = '.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS;.MSC' pathext = os.environ.get('PATHEXT', default_pathext) if use_bytes: pathext = os.fsencode(pathext).split(b';') else: pathext = pathext.split(';') for ext in pathext: files.append(cmd + ext) # If we're given a path with a directory part, look it up directly rather # than referring to PATH directories. This includes checking relative to the # current directory, e.g. ./script. if os.path.dirname(cmd): for file in files: if _access_check(file, mode): return file return None The author of the PATHEXT code in shutil.which() was following a source that documented the behavior incorrectly. CMD always looks for the filename before trying to append the PATHEXT extensions. It does not limit its search to PATHEXT extensions. The only exception is a file that has no extension, in which case "." has to be set in PATHEXT to get CMD to find the file. However, where.exe finds a file that has no extension, regardless of PATHEXT, so Python's which() should be free to follow that example. ---------- nosy: +eryksun stage: -> needs patch versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 00:42:11 2019 From: report at bugs.python.org (Jordon.X) Date: Thu, 22 Aug 2019 04:42:11 +0000 Subject: [issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores. In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org> Message-ID: <1566448931.18.0.178731144289.issue37751@roundup.psfhosted.org> Jordon.X <9651234 at qq.com> added the comment: Thanks vstinner. I also don't think it's necessary to backport to the old version. Close this issue is fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 00:55:31 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 22 Aug 2019 04:55:31 +0000 Subject: [issue29250] islink and stat follow_symlinks are inconsistent on Windows In-Reply-To: <1484217765.9.0.444376233166.issue29250@psf.upfronthosting.co.za> Message-ID: <1566449731.45.0.355692674131.issue29250@roundup.psfhosted.org> Change by Eryk Sun : ---------- dependencies: -os.walk always follows Windows junctions resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 00:57:30 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 22 Aug 2019 04:57:30 +0000 Subject: [issue37074] os.stat() does not work for NUL and CON In-Reply-To: <1559029061.14.0.328684807212.issue37074@roundup.psfhosted.org> Message-ID: <1566449850.85.0.49351586976.issue37074@roundup.psfhosted.org> Change by Eryk Sun : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 01:17:38 2019 From: report at bugs.python.org (Vinay Sharma) Date: Thu, 22 Aug 2019 05:17:38 +0000 Subject: [issue37754] Persistence of Shared Memory Segment after process exits In-Reply-To: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> Message-ID: <1566451058.75.0.501526363848.issue37754@roundup.psfhosted.org> Vinay Sharma added the comment: > In terms of providing "consistent behavior across platforms that can be > reasonably supported", the behavior suggested above could not > reasonably be supported in Windows. I understand that persistence of a shared memory segment after all the processes using it exit, can be very difficult on Windows. But, after testing shared_memory on Windows, the behavior on Windows and Unix is not consistent at the moment. For instance: Let's say a three processes P1, P2 and P3 are trying to communicate using shared memory. --> P1 creates the shared memory block, and waits for P2 and P3 to access it. --> P2 starts and attaches this shared memory segment, writes some data to it and exits. --> Now in case of Unix, shm_unlink is called as soon as P2 exits. --> Now, P3 starts and tries to attach the shared memory segment. --> P3 will not be able to attach the shared memory segment in Unix, because shm_unlink has been called on that segment. --> Whereas, P3 will be able to attach to the shared memory segment in Windows One possible solution can be, to register the shared the shared_memory only when it's created and not when it's attached. I think that might make Unix's implementation more consistent with windows. Any thoughts on the same will be very helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 01:28:36 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 22 Aug 2019 05:28:36 +0000 Subject: [issue37862] Search doesn't find built-in functions In-Reply-To: <1565831586.7.0.196033639625.issue37862@roundup.psfhosted.org> Message-ID: <1566451716.12.0.139098438709.issue37862@roundup.psfhosted.org> Terry J. Reedy added the comment: Even if click 'Library Reference', click '2. Built-in...', click name in the index at the top of the page to go to the entry I know I want to read is sometimes slower that 'click search box', enter word, hit Return, wait for results, scan results to find that entry, I prefer a consistent and dependable result. That said, perhaps the search algorithm should start with looking words up in the builtins list, the module index, the glossary, and the index, and display those first Index pages with definitions should get heavy weight too. But is seems from your example that the obvious places might be downweighted instead. As for my answer, I believe that the search once used Google, which was and still is terrible at returning results from the current doc. For instance, just now, the 2nd return for 'Python zip' is the zip entry in chapter 2 ... for 3.3.7! 'Python zip 3.7' does return https://docs.python.org/3/library/functions.html as first entry. I would rather click click to get to the same place. If Julien and Ammar can improve Search [ ] to beat that, and be consistently useful to beginners, more power to them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 01:40:27 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 22 Aug 2019 05:40:27 +0000 Subject: [issue37074] os.stat() does not work for NUL and CON In-Reply-To: <1559029061.14.0.328684807212.issue37074@roundup.psfhosted.org> Message-ID: <1566452427.5.0.409529465292.issue37074@roundup.psfhosted.org> Serhiy Storchaka added the comment: Where it was fixed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 01:50:48 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 05:50:48 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1566453048.61.0.771725170242.issue35889@roundup.psfhosted.org> Raymond Hettinger added the comment: If this goes forward, the maximum output size needs to be limited in some way (like what is done in reprlib). Given Serhiy's doubts, I'm only +0 on this. Feel free to close this if you like. For the most part, I don't think people even look at Row objects. ---------- versions: +Python 3.9 -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 02:04:02 2019 From: report at bugs.python.org (Marco Sulla) Date: Thu, 22 Aug 2019 06:04:02 +0000 Subject: [issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity In-Reply-To: <1565258224.48.0.98423013878.issue37792@roundup.psfhosted.org> Message-ID: <1566453842.59.0.0571945101849.issue37792@roundup.psfhosted.org> Marco Sulla added the comment: @rhettinger: "Deprecating [...] just cause disruption to existing, deployed code" How? Deprecating is used just to maintain intact the already existing code... "Please do not go down of the path of making yourself the arbiter of what is Pythonic or standard. The other core devs in this conversation are highly experienced. Insulting them or the Fredrik Lundh's existing API won't help matters" I'm not insulting anyone, I just said *IMHO* it's not pythonic. I think the example of a tree created with a simple dictionary is a clear signal that Python, in the Guido's mind, was created with the intention that equality should check the content of the objects and not just the ids, as Java, for example, does, even for objects that must be traversed to see if they are equal to another one. The fact you can check if two objects are equal using simply == is, _IMHO_, more elegant, simple and useful. The fact that == checks the ids is not useful at all, since I can do it with id(elem1) == id(elem2). So what's the purpose of == ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 02:06:42 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 22 Aug 2019 06:06:42 +0000 Subject: [issue37754] Persistence of Shared Memory Segment after process exits In-Reply-To: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> Message-ID: <1566454002.38.0.525858526679.issue37754@roundup.psfhosted.org> Eryk Sun added the comment: > register the shared the shared_memory only when it's created and > not when it's attached. In Windows, the section object is reference counted. I haven't looked into the Unix implementation, but maybe it could use advisory locking. After opening shared memory via shm_open, a process would try to acquire a shared lock on the fd. If it can't acquire the lock, close the fd and fail the open. When exiting, a process would remove its shared lock and try to acquire an exclusive lock. If it acquires an exclusive lock, it should call shm_unlink because it's the last reference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 02:17:01 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 06:17:01 +0000 Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or bytes literals In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org> Message-ID: <1566454621.51.0.804848857203.issue36906@roundup.psfhosted.org> Raymond Hettinger added the comment: We should consider dedicated syntax for compile-time dedenting: d"""\ This would be left aligned but this would only have four spaces And this would be left-justified. """ # Am not sure what to do about this last line ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 02:24:44 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 06:24:44 +0000 Subject: [issue32471] Add an UML class diagram to the collections.abc module documentation In-Reply-To: <1514785654.69.0.467229070634.issue32471@psf.upfronthosting.co.za> Message-ID: <1566455084.62.0.157544710823.issue32471@roundup.psfhosted.org> Raymond Hettinger added the comment: See the rationale in the closed PR. I rather liked this idea but it didn't prove to be a net win during user testing. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 02:43:48 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 06:43:48 +0000 Subject: [issue26680] Incorporating float.is_integer into the numeric tower and Decimal In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za> Message-ID: <1566456228.96.0.662309578532.issue26680@roundup.psfhosted.org> Raymond Hettinger added the comment: Marking this as closed: * no forward movement for a year and half * opposition from multiple core devs Feel free to revive this if you truly think this is needed and want to get the debate going again. Also, expanding the numeric tower is always going to be problematic, because any user type that currently registers with it will be instantly non-compliant. Concrete classes can grow APIs and keep backwards compatibility but abstract classes cannot easily grow new requirements. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 02:45:18 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 22 Aug 2019 06:45:18 +0000 Subject: [issue34410] itertools.tee not thread-safe; can segfault interpreter when wrapped iterator releases GIL In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za> Message-ID: <1566456318.98.0.349976175008.issue34410@roundup.psfhosted.org> Serhiy Storchaka added the comment: I tried to solve this issue myself, and figured out that it is not so simple. It is possible to make tee() nor crashing, but it is not possible to guarantee the order of the output without using a lock in tee(). It you can get a sequence 1, 2, 4, 3, ... So we have the following options: 1. Document that the tee() iterator can not be consumed from different threads, even if an underlying iterator is thread-safe. 2. Detect the race condition and raise a RuntimeError (as for iterating modifying dicts). 3. Fix a crash, but document that the tee() iterator can return items out of order if consumed from different threads (PR 9254 basically does this). And exceptions can be raised out of order too. 4. Add a non-reentrant lock in the tee() object and raise a RuntimeError if it is re-entered. 5. Add a reentrant lock in the tee() object. We can apply different solutions in developed and maintained versions. I would not backport options with locks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 02:57:04 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 22 Aug 2019 06:57:04 +0000 Subject: [issue37074] os.stat() does not work for NUL and CON In-Reply-To: <1559029061.14.0.328684807212.issue37074@roundup.psfhosted.org> Message-ID: <1566457024.55.0.602073155179.issue37074@roundup.psfhosted.org> Eryk Sun added the comment: > Where it was fixed? It was addressed in issue 37834. PR 15231 includes a rewrite of win32_xstat_impl. The file type was needed, so the rewrite could also address the problem of character devices such as CON and NUL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 02:58:48 2019 From: report at bugs.python.org (B Siemerink) Date: Thu, 22 Aug 2019 06:58:48 +0000 Subject: [issue37482] Email address display name fails with both encoded words and special chars In-Reply-To: <1562068275.57.0.247896906946.issue37482@roundup.psfhosted.org> Message-ID: <1566457128.83.0.558675467307.issue37482@roundup.psfhosted.org> Change by B Siemerink : ---------- pull_requests: +15090 pull_request: https://github.com/python/cpython/pull/15380 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 03:06:58 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 07:06:58 +0000 Subject: [issue14050] Tutorial, list.sort() and items comparability In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za> Message-ID: <1566457618.46.0.913943329905.issue14050@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +15091 pull_request: https://github.com/python/cpython/pull/15381 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 03:10:25 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 22 Aug 2019 07:10:25 +0000 Subject: [issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity In-Reply-To: <1565258224.48.0.98423013878.issue37792@roundup.psfhosted.org> Message-ID: <1566457825.43.0.563334408588.issue37792@roundup.psfhosted.org> Serhiy Storchaka added the comment: Closed since this issue contains several unrelated propositions, most of which have been rejected. If you want to add helper functions for comparing Elements (shallow and deep, with and without taking and order of attributes to account, with and without ignoring whitespaces, etc), feel free to open a separate issue. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 03:16:41 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 22 Aug 2019 07:16:41 +0000 Subject: [issue37894] [win] shutil.which can not find the path if 'cmd' include directory path and not include extension name In-Reply-To: <1566316777.4.0.882745227499.issue37894@roundup.psfhosted.org> Message-ID: <1566458201.88.0.839390960942.issue37894@roundup.psfhosted.org> Serhiy Storchaka added the comment: Do you mind to create a PR Eryk? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 03:18:03 2019 From: report at bugs.python.org (paul j3) Date: Thu, 22 Aug 2019 07:18:03 +0000 Subject: [issue37910] argparse wrapping fails with metavar="" (no metavar) In-Reply-To: <1566425299.96.0.375120843288.issue37910@roundup.psfhosted.org> Message-ID: <1566458283.7.0.847280132716.issue37910@roundup.psfhosted.org> paul j3 added the comment: That usage formatting is extremely brittle. It's not just "" metavar that can mess it up. Other 'usual' characters can mess it in the same way. The underlying problem is that it formats the whole usage, and if it is too long tries to split it into pieces, and then reassemble it in wrapped lines. The assertion tries to verify that the split was accurate. Usage really needs to be rewritten in a way that keeps the individual Action pieces separate until it is ready to assemble them into final lines. Anything else is just bandaids. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 03:20:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 07:20:06 +0000 Subject: [issue17306] Improve the way abstract base classes are shown in help() In-Reply-To: <1361932149.15.0.421194254516.issue17306@psf.upfronthosting.co.za> Message-ID: <1566458406.27.0.0205627928592.issue17306@roundup.psfhosted.org> Raymond Hettinger added the comment: There is just a little more work to do on this. 1) The class level docstrings needs to display which methods are required. Sequence.__doc__ already does a good job of this but most of the other classes are missing docstrings or don't specific the needed methods. 2) Methods like Sequence.count and Mapping.__eq__ already have a good docstrings but there is nothing for most of the other methods. The docstring should be modeled on that for the corresponding methods in the concrete classes (list.__getitem__ for example). ---------- keywords: +newcomer friendly versions: +Python 3.8, Python 3.9 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 03:23:05 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 07:23:05 +0000 Subject: [issue24659] dict() built-in fails on iterators with a "keys" attribute In-Reply-To: <1437209700.05.0.411435282726.issue24659@psf.upfronthosting.co.za> Message-ID: <1566458585.81.0.0273073490611.issue24659@roundup.psfhosted.org> Raymond Hettinger added the comment: This doesn't appear to have been an ongoing source of confusion. Over time, the existence of the glossary entries and the collections ABCs seems to have provided the needed clarity. ---------- resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 03:32:30 2019 From: report at bugs.python.org (Robert Smallshire) Date: Thu, 22 Aug 2019 07:32:30 +0000 Subject: [issue26680] Incorporating float.is_integer into the numeric tower and Decimal In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za> Message-ID: <1566459150.35.0.177012662864.issue26680@roundup.psfhosted.org> Robert Smallshire added the comment: > * no forward movement for a year and half For most of that year and a half my pull-request was sitting in Github awaiting review by two core devs, of which you Raymond, were one. I don't like to hassle people who contribute their free time to Python and assumed you or the other reviewer would get around to it good time. Mark Dickinson kindly reviewed the my changes shortly before the 3.8 window closed, but I didn't have capacity to follow up before it was too late. The changes Mark wanted were largely to do with in-code documentation rather than the the substance of the change. Assuming it really is too late for 3.8, even if I made the changes Mark wanted immediately, I would like to see this change in 3.9. > * opposition from multiple core devs Guido approved the change in a pronouncement on python-dev. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 04:03:24 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 08:03:24 +0000 Subject: [issue26680] Incorporating float.is_integer into the numeric tower and Decimal In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za> Message-ID: <1566461004.55.0.432923742029.issue26680@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: rejected -> versions: +Python 3.9 -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 04:28:48 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 08:28:48 +0000 Subject: [issue26680] Incorporating float.is_integer into the numeric tower and Decimal In-Reply-To: <1459452864.35.0.120403756979.issue26680@psf.upfronthosting.co.za> Message-ID: <1566462528.63.0.130269588219.issue26680@roundup.psfhosted.org> Raymond Hettinger added the comment: Guido, when you approved this did you intend for the numeric tower to be amended as well? We elected not to do so for as_integer_ratio() and the same choice should be made here (because it's hard to add methods to ABCs without breaking existing user classes registered to that ABC). FWIW, it's not too late to change your mind about doing this at all. I don't see this as a feature in other languages and even the ultra thorough decimal arithmetic specification elected not to include this method. The benefits are somewhat dubious but new method counts are certain: len(dir(int)) == 72 ---------- assignee: -> gvanrossum nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 04:36:56 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 08:36:56 +0000 Subject: [issue34410] itertools.tee not thread-safe; can segfault interpreter when wrapped iterator releases GIL In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za> Message-ID: <1566463016.78.0.641479058606.issue34410@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks for enumerating the options. I think 1 and 2 are the best combination. It is a reasonable restriction to not tee across threads. If someone still does, then detecting it, raising an exception, and not crashing seem like a reasonable response. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 05:03:27 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 09:03:27 +0000 Subject: [issue32554] random.seed(tuple) uses the randomized hash function and so is not reproductible In-Reply-To: <1516007302.18.0.467229070634.issue32554@psf.upfronthosting.co.za> Message-ID: <1566464607.19.0.0899551966463.issue32554@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +15092 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15382 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 05:06:49 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 09:06:49 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1566464809.17.0.24038287241.issue16468@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +newcomer friendly -patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 05:17:24 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 09:17:24 +0000 Subject: [issue28988] Switch dict and set structures to PyVarObject In-Reply-To: <1481900465.81.0.491407063999.issue28988@psf.upfronthosting.co.za> Message-ID: <1566465444.1.0.223999818227.issue28988@roundup.psfhosted.org> Raymond Hettinger added the comment: > Since I don't see a benefit from this change I leave both patches > to you Raymond. After more reflection, I also don't see any point of doing this. While there is a minor whiff of consistency when using Py_SIZE(), it makes the assignment look weird and inconsistent between filled and used. I now favor local consistency and clarity (with in setobject.c) over trying to make it look exactly like some other modules. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 05:39:08 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Aug 2019 09:39:08 +0000 Subject: [issue37528] test_tarfile: test_extractall_symlinks() fails on Windows with: [WinError 206] The filename or extension is too long In-Reply-To: <1562672057.8.0.696699034391.issue37528@roundup.psfhosted.org> Message-ID: <1566466748.65.0.650094978883.issue37528@roundup.psfhosted.org> STINNER Victor added the comment: Hum, tests are still failing, example on AMD64 Windows8.1 Non-Debug 3.x: https://buildbot.python.org/all/#/builders/12/builds/2992 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 05:39:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 09:39:06 +0000 Subject: [issue13451] sched.py: speedup cancel() method In-Reply-To: <1321923822.73.0.49972384361.issue13451@psf.upfronthosting.co.za> Message-ID: <1566466746.58.0.598776217159.issue13451@roundup.psfhosted.org> Raymond Hettinger added the comment: I no longer think this should be done. For most applications, cancel() speed is the least important task and isn't worth adding any extra baggage to the run() loop. The current cancel() code is only slow if the length is somewhat large (atypical for a scheduling app). Also, to my eyes the patch more than doubles the complexity of the module (which can currently be almost completely understood by examining the short run-loop). Lastly, a lazy cancel() keeps the references around longer (which may be undesirable for some apps). If you really think this module needs a lazy cancel(), then press ahead. Otherwise, we have no evidence that this a problem in the real world. The current cancel call is O(n) but runs at C speed which should be plenty fast enough for most cases. ---------- assignee: rhettinger -> serhiy.storchaka versions: +Python 3.9 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 05:39:44 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Aug 2019 09:39:44 +0000 Subject: [issue9949] os.path.realpath on Windows does not follow symbolic links In-Reply-To: <1285426994.28.0.192028764756.issue9949@psf.upfronthosting.co.za> Message-ID: <1566466784.45.0.928083260317.issue9949@roundup.psfhosted.org> STINNER Victor added the comment: It seems like Windows buildbots are back to green (fixed), thanks ;-) ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 06:05:04 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 10:05:04 +0000 Subject: [issue20727] Improved roundrobin itertools recipe In-Reply-To: <1393051018.22.0.696460210134.issue20727@psf.upfronthosting.co.za> Message-ID: <1566468304.71.0.322228797654.issue20727@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks for the suggestion. I appreciate it even though I've decided to keep the current recipe. While he proposed recipe is really good at eliminating exhausted input sources, it is slower at its core task of yielding outputs (which is typically the important part). The O(n) step in the current code runs at C speed and is really fast. On my six year old machine, running :cycle(islice(nexts, num_active))" for 1,000 nexts takes only 186ns. One other thought: The existing recipe is also useful for showing off ways to use the itertools (which was really the principal purpose of having a recipes section). ---------- resolution: remind -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 06:17:07 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Thu, 22 Aug 2019 10:17:07 +0000 Subject: [issue37913] Document that __length_hint__ may return NotImplemented Message-ID: <1566469027.85.0.30597516641.issue37913@roundup.psfhosted.org> New submission from Jeroen Demeyer : The special method __length_hint__ can return NotImplemented. In this case, the result is as if the __length_hint__ method didn't exist at all. This behaviour is implemented and tested but not documented. ---------- assignee: docs at python components: Documentation messages: 350180 nosy: docs at python, jdemeyer priority: normal severity: normal status: open title: Document that __length_hint__ may return NotImplemented type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 06:26:51 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Thu, 22 Aug 2019 10:26:51 +0000 Subject: [issue37913] Document that __length_hint__ may return NotImplemented In-Reply-To: <1566469027.85.0.30597516641.issue37913@roundup.psfhosted.org> Message-ID: <1566469611.34.0.981668723814.issue37913@roundup.psfhosted.org> Change by Jeroen Demeyer : ---------- keywords: +patch pull_requests: +15093 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15383 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 06:42:55 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 22 Aug 2019 10:42:55 +0000 Subject: [issue27961] remove support for platforms without "long long" In-Reply-To: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za> Message-ID: <1566470575.8.0.144578825057.issue27961@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- pull_requests: +15094 pull_request: https://github.com/python/cpython/pull/15385 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 06:44:50 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Aug 2019 10:44:50 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566470690.43.0.843884962339.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: Oh, I found an issue with regrtest and Windows processes. On Windows, when a process dies (crash or whatever), Popen.communicate() continues to hang in the parent if the died process has at least one child process which is still alive. Test attached kill_timeout.py: --- vstinner at WIN C:\vstinner\python\master>python x.py Running Debug|x64 interpreter... parent pid 1600 child1 pid 2184 child2 pid 4516 communicate(): timeout (1) child1 killed wait() returned: returncode 1 communicate() timeout (2) --- Calling Popen.communicate() hangs even if the child process has been killed, whereas wait() completes immediately. On Windows, Popen.communicate() is implemented with threads calling this function on each pipe: def _readerthread(self, fh, buffer): buffer.append(fh.read()) fh.close() It seems like self.stdout.read() hangs even after the child process has been killed. ---------- Added file: https://bugs.python.org/file48555/kill_timeout.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 06:48:13 2019 From: report at bugs.python.org (Elinaldo Monteiro) Date: Thu, 22 Aug 2019 10:48:13 +0000 Subject: [issue37914] class timedelta, support the method hours and minutes in field accessors Message-ID: <1566470893.59.0.211009594568.issue37914@roundup.psfhosted.org> New submission from Elinaldo Monteiro : Hello, Does it make sense to exist theses 2 methods in class timedelta? @property def hours(self): return self._seconds // 3600 @property def minutes(self): return self._seconds // 60 ---------- messages: 350182 nosy: elinaldosoft priority: normal severity: normal status: open title: class timedelta, support the method hours and minutes in field accessors type: enhancement versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 06:48:57 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Aug 2019 10:48:57 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566470937.36.0.360542823741.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: The issue can be reproduced with regrtest: * Copy attached test_kill.py to Lib/test/ * Run: python -m test test_kill -v -j2 --timeout=5 I also applied the following changes to regrtest: diff --git a/Lib/test/libregrtest/runtest.py b/Lib/test/libregrtest/runtest.py index e7dce180cb..7d996d6918 100644 --- a/Lib/test/libregrtest/runtest.py +++ b/Lib/test/libregrtest/runtest.py @@ -119,7 +119,7 @@ def _runtest(ns, test_name): use_timeout = (ns.timeout is not None) if use_timeout: - faulthandler.dump_traceback_later(ns.timeout, exit=True) + pass #faulthandler.dump_traceback_later(ns.timeout, exit=True) start_time = time.perf_counter() try: diff --git a/Lib/test/libregrtest/runtest_mp.py b/Lib/test/libregrtest/runtest_mp.py index c22479b797..51352497ae 100644 --- a/Lib/test/libregrtest/runtest_mp.py +++ b/Lib/test/libregrtest/runtest_mp.py @@ -19,10 +19,10 @@ from test.libregrtest.utils import format_duration # Display the running tests if nothing happened last N seconds -PROGRESS_UPDATE = 30.0 # seconds +PROGRESS_UPDATE = 1.0 # seconds # Time to wait until a worker completes: should be immediate -JOIN_TIMEOUT = 30.0 # seconds +JOIN_TIMEOUT = 5.0 # seconds def must_stop(result, ns): @@ -305,7 +305,7 @@ class MultiprocessRunner: self.pending = MultiprocessIterator(self.regrtest.tests) if self.ns.timeout is not None: self.worker_timeout = self.ns.timeout * 1.5 - self.main_timeout = self.ns.timeout * 2.0 + self.main_timeout = self.ns.timeout * 10.0 else: self.worker_timeout = None self.main_timeout = None ---------- Added file: https://bugs.python.org/file48556/test_kill.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 06:51:30 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 22 Aug 2019 10:51:30 +0000 Subject: [issue37914] class timedelta, support the method hours and minutes in field accessors In-Reply-To: <1566470893.59.0.211009594568.issue37914@roundup.psfhosted.org> Message-ID: <1566471090.06.0.115917448276.issue37914@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +belopolsky, p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 07:05:11 2019 From: report at bugs.python.org (Ma Lin) Date: Thu, 22 Aug 2019 11:05:11 +0000 Subject: [issue37907] speed-up PyLong_As*() for large longs In-Reply-To: <1566404262.5.0.0996699211051.issue37907@roundup.psfhosted.org> Message-ID: <1566471911.38.0.910151848486.issue37907@roundup.psfhosted.org> Change by Ma Lin : ---------- nosy: +Ma Lin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 07:18:39 2019 From: report at bugs.python.org (Tom Augspurger) Date: Thu, 22 Aug 2019 11:18:39 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and putz.utc Message-ID: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> New submission from Tom Augspurger : The following crashes with Python 3.8b3 ``` import sys import pytz import datetime print(sys.version_info) print(pytz.__version__) print(datetime.timezone.utc == pytz.utc) ``` When run with `-X faulthandler`, I see ``` sys.version_info(major=3, minor=8, micro=0, releaselevel='beta', serial=3) 2019.2 Fatal Python error: Segmentation fault Current thread 0x00000001138dc5c0 (most recent call first): File "foo.py", line 8 in Segmentation fault: 11 ``` ---------- messages: 350184 nosy: tomaugspurger priority: normal severity: normal status: open title: Segfault in comparison between datetime.timezone.utc and putz.utc type: crash versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 07:21:12 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 22 Aug 2019 11:21:12 +0000 Subject: [issue27961] remove support for platforms without "long long" In-Reply-To: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za> Message-ID: <1566472872.89.0.28162217775.issue27961@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- pull_requests: +15095 pull_request: https://github.com/python/cpython/pull/15386 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 07:37:17 2019 From: report at bugs.python.org (=?utf-8?q?Jakub_Piotr_C=C5=82apa?=) Date: Thu, 22 Aug 2019 11:37:17 +0000 Subject: [issue37916] distutils: allow overriding of the RANLIB command on macOS (darwin) Message-ID: <1566473837.96.0.294748627211.issue37916@roundup.psfhosted.org> New submission from Jakub Piotr C?apa : On a macOS hosts the system ranlib does not understand ELF files so using the "ranlib" command causes errors during cross-compilations. The simplest way to fix it is to pass the RANLIB parameter provided to setup.py through to the distutils compiler machinery. This is analogous to the way the C/C++ cross-compiler is configured. This change (in a GitHub PR) was required to proceed with crosscompiling numpy. It should help with other packages too (if they use distutils and need ranlib). ---------- components: Cross-Build messages: 350185 nosy: Alex.Willmer, Jakub Piotr C?apa priority: normal severity: normal status: open title: distutils: allow overriding of the RANLIB command on macOS (darwin) type: compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 07:38:50 2019 From: report at bugs.python.org (Roundup Robot) Date: Thu, 22 Aug 2019 11:38:50 +0000 Subject: [issue37916] distutils: allow overriding of the RANLIB command on macOS (darwin) In-Reply-To: <1566473837.96.0.294748627211.issue37916@roundup.psfhosted.org> Message-ID: <1566473930.23.0.454819054574.issue37916@roundup.psfhosted.org> Change by Roundup Robot : ---------- keywords: +patch pull_requests: +15096 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15387 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 07:42:22 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 22 Aug 2019 11:42:22 +0000 Subject: [issue37907] speed-up PyLong_As*() for large longs In-Reply-To: <1566404262.5.0.0996699211051.issue37907@roundup.psfhosted.org> Message-ID: <1566474142.15.0.941429224545.issue37907@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka, vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 07:45:16 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 22 Aug 2019 11:45:16 +0000 Subject: [issue27961] remove support for platforms without "long long" In-Reply-To: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za> Message-ID: <1566474316.42.0.82315276615.issue27961@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- pull_requests: +15098 pull_request: https://github.com/python/cpython/pull/15388 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 07:45:51 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 22 Aug 2019 11:45:51 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and putz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566474351.75.0.411340842427.issue37915@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I am adding 3.8 regression since the code works with 3.7 though it involves pytz. ---------- keywords: +3.8regression nosy: +belopolsky, p-ganssle, xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 07:46:19 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 22 Aug 2019 11:46:19 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566474379.77.0.362683372113.issue37915@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- title: Segfault in comparison between datetime.timezone.utc and putz.utc -> Segfault in comparison between datetime.timezone.utc and pytz.utc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 07:52:11 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 22 Aug 2019 11:52:11 +0000 Subject: [issue37914] class timedelta, support the method hours and minutes in field accessors In-Reply-To: <1566470893.59.0.211009594568.issue37914@roundup.psfhosted.org> Message-ID: <1566474731.12.0.0551031967399.issue37914@roundup.psfhosted.org> Serhiy Storchaka added the comment: It was already proposed several times before. The problem is that what do you expect to get from timedelta(hours=24).hours? The idiomatic way to convert a timedelta object to a number of hours is: td = timedelta(...) number_of_hours = td // timedelta(hours=1) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 08:08:13 2019 From: report at bugs.python.org (Elinaldo Monteiro) Date: Thu, 22 Aug 2019 12:08:13 +0000 Subject: [issue37914] class timedelta, support the method hours and minutes in field accessors In-Reply-To: <1566470893.59.0.211009594568.issue37914@roundup.psfhosted.org> Message-ID: <1566475693.64.0.164220041491.issue37914@roundup.psfhosted.org> Elinaldo Monteiro added the comment: Imagine the following scenario. from datetime import timedelta diff = timedelta(hours=23, minutes=59) - timedelta(hours=20, minutes=45) Which is the simplest ? diff.hours diff.total_seconds() // 3600 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 08:34:33 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 22 Aug 2019 12:34:33 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566477273.33.0.219282407436.issue37915@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Seems this is due to issue37685 (dde944f9df) on bisecting datetime related changes. Adding Serhiy. I guess this could be marked as release blocker. Here is a simplified reproducer on extracting pytz.utc source [0] which is an object of simple subclass of datetime.tzinfo : import sys import datetime print(sys.version) class UTC(datetime.tzinfo): pass print(datetime.timezone.utc == UTC()) datetime.timezone.utc == datetime.tzinfo() # This also segfaults without a subclass and should be False # Segfaults ? cpython git:(dde944f9df) git checkout dde944f9df && make -s -j4 > /dev/null HEAD is now at dde944f9df bpo-37685: Fixed comparisons of datetime.timedelta and datetime.timezone. (GH-14996) ? cpython git:(dde944f9df) ./python.exe ../backups/bpo37915.py 3.8.0b3+ (tags/v3.8.0b3-30-gdde944f9df:dde944f9df, Aug 22 2019, 17:55:14) [Clang 7.0.2 (clang-700.1.81)] [1] 33988 segmentation fault ./python.exe ../backups/bpo37915.py # Commit before works fine ? cpython git:(dde944f9df) git checkout dde944f9df~1 && make -s -j4 > /dev/null Previous HEAD position was dde944f9df bpo-37685: Fixed comparisons of datetime.timedelta and datetime.timezone. (GH-14996) HEAD is now at 4e402d37eb Correct description of HTTP status code 308. (GH-15098) ? cpython git:(4e402d37eb) ./python.exe ../backups/bpo37915.py 3.8.0b3+ (tags/v3.8.0b3-30-gdde944f9df:dde944f9df, Aug 22 2019, 17:55:14) [Clang 7.0.2 (clang-700.1.81)] False [0] https://github.com/stub42/pytz/blob/62f872054dde69e5c510094093cd6e221d96d5db/src/pytz/__init__.py#L256 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 10:28:22 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 22 Aug 2019 14:28:22 +0000 Subject: [issue26680] Incorporating float.is_integer into the numeric tower and Decimal In-Reply-To: <1566462528.63.0.130269588219.issue26680@roundup.psfhosted.org> Message-ID: Guido van Rossum added the comment: It should not go on the numeric tower. -- --Guido (mobile) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:00:41 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 22 Aug 2019 15:00:41 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566486041.38.0.807256519257.issue37531@roundup.psfhosted.org> Eryk Sun added the comment: > It seems like self.stdout.read() hangs even after the child process > has been killed. This is an issue when the standard handles are inherited or duplicated to a grandchild process, and so on. In the case of Popen(sys.executable), the system is duplicating the standard handles implicitly because sys.executable is a console process (assuming it's python[_d].exe), among other criteria. An additional reference on the write side prevents the pipe from closing. fh.read() in the grandparent won't return as long as there's a writer that could potentially write more data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:05:52 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Thu, 22 Aug 2019 15:05:52 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566486352.16.0.474524091142.issue37884@roundup.psfhosted.org> Jeroen Demeyer added the comment: May I propose PR 15327 as alternative? It solves some of the same issues as the PR on this issue, in particular supporting arbitrary objects with as_integer_ratio(). It also improves performance somewhat for certain inputs, but that's more by accident. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:08:13 2019 From: report at bugs.python.org (Zackery Spytz) Date: Thu, 22 Aug 2019 15:08:13 +0000 Subject: [issue37549] os.dup() fails for standard streams on Windows 7 In-Reply-To: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org> Message-ID: <1566486493.7.0.00273153460705.issue37549@roundup.psfhosted.org> Change by Zackery Spytz : ---------- keywords: +patch pull_requests: +15099 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15389 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:12:46 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 22 Aug 2019 15:12:46 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566486766.81.0.55669844431.issue37915@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +15100 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15390 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:13:14 2019 From: report at bugs.python.org (Steve Dower) Date: Thu, 22 Aug 2019 15:13:14 +0000 Subject: [issue37549] os.dup() fails for standard streams on Windows 7 In-Reply-To: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org> Message-ID: <1566486794.94.0.926554189764.issue37549@roundup.psfhosted.org> Steve Dower added the comment: Thanks Zackery for the patch! > The problem is just console pseudohandles in Windows 7 and earlier. Should we add a version check as well [1]? I'm not totally comfortable with bitmasking a handle here, but if we only do this additional check on Win7 then I'm okay with it. And if we add the check, I'd rather this be a function than a macro. It's getting too complicated to read :) [1]: https://docs.microsoft.com/en-us/windows/win32/api/versionhelpers/nf-versionhelpers-iswindows8orgreater ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:19:23 2019 From: report at bugs.python.org (Tom Augspurger) Date: Thu, 22 Aug 2019 15:19:23 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566487163.0.0.382953344156.issue37915@roundup.psfhosted.org> Tom Augspurger added the comment: Thanks for debugging this Karthikeyan and for the quick fix Pablo! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:20:25 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 22 Aug 2019 15:20:25 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566487225.39.0.450029650141.issue37915@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: This is due to an incorrect type check in the timezone_richcompare, it should be a comparison against PyDateTime_TimeZoneType not against PyDateTime_TZInfoType. The segfault is due to an invalid casting to PyDateTime_TimeZoneType (the child) from the parent (PyDateTime_TZInfoType). ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:21:06 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 22 Aug 2019 15:21:06 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566487266.25.0.395925382288.issue37915@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Thanks, Tom and Karthikeyan for the finding and the debugging :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:28:32 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 22 Aug 2019 15:28:32 +0000 Subject: [issue27961] remove support for platforms without "long long" In-Reply-To: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za> Message-ID: <1566487712.8.0.444357681031.issue27961@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: New changeset a38e9d139929a227e3899fbb638bc46c6cc6d8ba by Pablo Galindo (Sergey Fedoseev) in branch 'master': bpo-27961: Remove leftovers from the times when long long wasn't required (GH-15388) https://github.com/python/cpython/commit/a38e9d139929a227e3899fbb638bc46c6cc6d8ba ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:28:48 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 15:28:48 +0000 Subject: [issue27961] remove support for platforms without "long long" In-Reply-To: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za> Message-ID: <1566487728.38.0.418523974543.issue27961@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15101 pull_request: https://github.com/python/cpython/pull/15392 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:28:55 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 15:28:55 +0000 Subject: [issue27961] remove support for platforms without "long long" In-Reply-To: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za> Message-ID: <1566487735.91.0.809059013214.issue27961@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15102 pull_request: https://github.com/python/cpython/pull/15393 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:35:14 2019 From: report at bugs.python.org (Michael Anckaert) Date: Thu, 22 Aug 2019 15:35:14 +0000 Subject: [issue37914] class timedelta, support the method hours and minutes in field accessors In-Reply-To: <1566470893.59.0.211009594568.issue37914@roundup.psfhosted.org> Message-ID: <1566488114.41.0.0721901658233.issue37914@roundup.psfhosted.org> Michael Anckaert added the comment: I would support this addition. The timedelta class already has accessors for days and seconds, why not for hours and minutes? The implementation should make use of the idiomatic way as Serhiy mentioned. >>> timedelta(hours=25).seconds // 3600 1 Is wrong, it should be >>> timedelta(hours=25) // timedelta(hours=1) 25 >>> timedelta(hours=24) // timedelta(hours=1) 24 ---------- nosy: +michaelanckaert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:42:02 2019 From: report at bugs.python.org (Michael Anckaert) Date: Thu, 22 Aug 2019 15:42:02 +0000 Subject: [issue17306] Improve the way abstract base classes are shown in help() In-Reply-To: <1361932149.15.0.421194254516.issue17306@psf.upfronthosting.co.za> Message-ID: <1566488522.66.0.543254533899.issue17306@roundup.psfhosted.org> Michael Anckaert added the comment: I would be very interested and motivated to work on this. I'll start by taking a look at the pointers Raymond gave. If anyone can chime in with some more information / guidance that would be awesome. ---------- nosy: +michaelanckaert _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:46:25 2019 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 22 Aug 2019 15:46:25 +0000 Subject: [issue37914] class timedelta, support the method hours and minutes in field accessors In-Reply-To: <1566470893.59.0.211009594568.issue37914@roundup.psfhosted.org> Message-ID: <1566488785.38.0.805722513539.issue37914@roundup.psfhosted.org> Paul Ganssle added the comment: > I would support this addition. The timedelta class already has accessors for days and seconds, why not for hours and minutes? The `timedelta.days` and `timedelta.seconds` accessors do not do what is being requested here. The component accessors just give you a given component of the timedelta in its normalized form, so: >>> td = timedelta(hours=25, minutes=1, seconds=2) >>> td.days 1 >>> td.seconds 3662 >>> td // timedelta(seconds=1) 90062 The reason there is no hours or minutes is that the normalized form of timedelta doesn't have those components. It would be inconsistent to have `hours` and `minutes` give the total duration of the timedelta in the chosen units while `.days` and `.seconds` return just the component of the normalized form. What's really being asked for here are `total_hours()` and `total_minutes()` methods, and when that has come up in the past (including recently on the python-dev mailing list), we've largely decided that the "divide by the units you want" idiom is sufficient (and in fact better in that you can choose any arbitrary units rather than just the ones that have specific names). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:50:12 2019 From: report at bugs.python.org (Michael Anckaert) Date: Thu, 22 Aug 2019 15:50:12 +0000 Subject: [issue37914] class timedelta, support the method hours and minutes in field accessors In-Reply-To: <1566488785.38.0.805722513539.issue37914@roundup.psfhosted.org> Message-ID: Michael Anckaert added the comment: Thank you for the clarification Paul. It makes sense to me now to not include those accessors. On Thu, 22 Aug 2019 at 17:46, Paul Ganssle wrote: > > Paul Ganssle added the comment: > > > I would support this addition. The timedelta class already has accessors > for days and seconds, why not for hours and minutes? > > The `timedelta.days` and `timedelta.seconds` accessors do not do what is > being requested here. The component accessors just give you a given > component of the timedelta in its normalized form, so: > > >>> td = timedelta(hours=25, minutes=1, seconds=2) > >>> td.days > 1 > >>> td.seconds > 3662 > >>> td // timedelta(seconds=1) > 90062 > > > The reason there is no hours or minutes is that the normalized form of > timedelta doesn't have those components. It would be inconsistent to have > `hours` and `minutes` give the total duration of the timedelta in the > chosen units while `.days` and `.seconds` return just the component of the > normalized form. > > What's really being asked for here are `total_hours()` and > `total_minutes()` methods, and when that has come up in the past (including > recently on the python-dev mailing list), we've largely decided that the > "divide by the units you want" idiom is sufficient (and in fact better in > that you can choose any arbitrary units rather than just the ones that have > specific names). > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:50:18 2019 From: report at bugs.python.org (Michael Anckaert) Date: Thu, 22 Aug 2019 15:50:18 +0000 Subject: [issue37917] Warning regarding collections ABCs still present in 3.9 Message-ID: <1566489018.68.0.646926687827.issue37917@roundup.psfhosted.org> New submission from Michael Anckaert : When importing an ABC from the collections module in Python 3.9 there is a warning that this is deprecated since Python 3.3 and will stop working in Python 3.9. Should this warning be removed and lead to an ImportError? Python 3.9.0a0 (heads/master:a38e9d1399, Aug 22 2019, 17:48:16) [GCC 8.3.1 20190223 (Red Hat 8.3.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from collections import Sequence :1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working ---------- components: Library (Lib) messages: 350202 nosy: michaelanckaert priority: normal severity: normal status: open title: Warning regarding collections ABCs still present in 3.9 type: behavior versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:54:09 2019 From: report at bugs.python.org (Marco Sulla) Date: Thu, 22 Aug 2019 15:54:09 +0000 Subject: [issue37918] What about an enum for open() modes? Message-ID: <1566489249.72.0.0117548525062.issue37918@roundup.psfhosted.org> New submission from Marco Sulla : As title. I just created it: https://pastebin.com/pNYezw2V I think it could be useful to have a more descriptive way to declare a file open mode. Many languages has an enum for this. Maybe open(), os.fdopen(), os.popen() and pathlib.Path.open() can just accept also an OpenMode enum as mode parameter, without the need to write OpenMode.append.value, for example, but just OpenMode.append. As an alternative, OpenMode could be a namedtuple. I don't know in which module should be put. In `builtins`, `os` or `pathlib`? ---------- components: Library (Lib) messages: 350203 nosy: Marco Sulla priority: normal severity: normal status: open title: What about an enum for open() modes? versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:54:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Aug 2019 15:54:25 +0000 Subject: [issue37917] Warning regarding collections ABCs still present in 3.9 In-Reply-To: <1566489018.68.0.646926687827.issue37917@roundup.psfhosted.org> Message-ID: <1566489265.99.0.7738165267.issue37917@roundup.psfhosted.org> STINNER Victor added the comment: It's a work-in-progress: see bpo-37324. ---------- nosy: +vstinner resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> collections: remove deprecated aliases to ABC classes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:56:41 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 22 Aug 2019 15:56:41 +0000 Subject: [issue37917] Warning regarding collections ABCs still present in 3.9 In-Reply-To: <1566489018.68.0.646926687827.issue37917@roundup.psfhosted.org> Message-ID: <1566489401.64.0.557270943672.issue37917@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Please see discussion at issue36953 and issue37324. It's currently blocked by Jinja that doesn't have a release with the fix to be used in CI. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 11:59:21 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 15:59:21 +0000 Subject: [issue27961] remove support for platforms without "long long" In-Reply-To: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za> Message-ID: <1566489561.61.0.538375553162.issue27961@roundup.psfhosted.org> miss-islington added the comment: New changeset 2878f378e02990303a8fe4bedd5386bd90efc26d by Miss Islington (bot) in branch '3.8': bpo-27961: Remove leftovers from the times when long long wasn't required (GH-15388) https://github.com/python/cpython/commit/2878f378e02990303a8fe4bedd5386bd90efc26d ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 12:06:11 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 16:06:11 +0000 Subject: [issue27961] remove support for platforms without "long long" In-Reply-To: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za> Message-ID: <1566489971.85.0.78279546414.issue27961@roundup.psfhosted.org> miss-islington added the comment: New changeset d0da97de65985ea4fc69cade2343d931f8b9efcd by Miss Islington (bot) in branch '3.7': bpo-27961: Remove leftovers from the times when long long wasn't required (GH-15388) https://github.com/python/cpython/commit/d0da97de65985ea4fc69cade2343d931f8b9efcd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 12:11:38 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 16:11:38 +0000 Subject: [issue14050] Tutorial, list.sort() and items comparability In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za> Message-ID: <1566490298.2.0.58477747932.issue14050@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 4109263a7edce11194e301138cf66fa2d07f7ce4 by Raymond Hettinger in branch 'master': bpo-14050: Note that not all data can be sorted (GH-15381) https://github.com/python/cpython/commit/4109263a7edce11194e301138cf66fa2d07f7ce4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 12:11:45 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 16:11:45 +0000 Subject: [issue14050] Tutorial, list.sort() and items comparability In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za> Message-ID: <1566490305.31.0.307433691797.issue14050@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15103 pull_request: https://github.com/python/cpython/pull/15395 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 12:19:39 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 16:19:39 +0000 Subject: [issue32554] random.seed(tuple) uses the randomized hash function and so is not reproductible In-Reply-To: <1516007302.18.0.467229070634.issue32554@psf.upfronthosting.co.za> Message-ID: <1566490779.75.0.243628024499.issue32554@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset d0cdeaab76fef8a6e5a04665df226b6659111e4e by Raymond Hettinger in branch 'master': bpo-32554: Deprecate hashing arbitrary types in random.seed() (GH-15382) https://github.com/python/cpython/commit/d0cdeaab76fef8a6e5a04665df226b6659111e4e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 12:20:08 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 16:20:08 +0000 Subject: [issue32554] random.seed(tuple) uses the randomized hash function and so is not reproductible In-Reply-To: <1516007302.18.0.467229070634.issue32554@psf.upfronthosting.co.za> Message-ID: <1566490808.64.0.873939979795.issue32554@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 Aug 22 12:24:09 2019 From: report at bugs.python.org (George Zhang) Date: Thu, 22 Aug 2019 16:24:09 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566491049.15.0.568069714476.issue37902@roundup.psfhosted.org> George Zhang added the comment: I renamed mousescroll to handlescroll as it's an independent callback function and I think it fits its use case better. I can keep it as mousescroll if you like though. The handlescroll function is now a standalone module function in tree.py and the EditorWindow imports it for use (instead of creating its own function). Its signature is `handlescroll(event, widget=None)` where event is the event (yeah...) and widget is an optional argument that overrides the widget to call `yview(SCROLL, lines, "units")` on. The second argument was added so that the nasty labels don't have to use the same function but with one line changed (we redirect handlescroll to use `self.canvas` because `event.widget` would refer to the Label which has no yview function). I've added tests on handlescroll with different events. I've also added a test on multicall that checks to test if MultiCallCreator overrides yview. Sorry about the PR closing and reopening. I was panicking about commiting more than once and saw that I should make a new branch for the patch (instead of using master branch). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 12:30:18 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 22 Aug 2019 16:30:18 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <1566491418.73.0.710245722292.issue28556@roundup.psfhosted.org> Change by Ivan Levkivskyi : ---------- pull_requests: +15104 pull_request: https://github.com/python/cpython/pull/15396 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 12:35:30 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 16:35:30 +0000 Subject: [issue23987] docs about containers membership testing wrong for broken objects In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za> Message-ID: <1566491730.09.0.943475350887.issue23987@roundup.psfhosted.org> Raymond Hettinger added the comment: It looks like the identity-implies-equality part of this has already been taken care of. The __hash__ invariant also appears to now have extensive coverage, some in the glossary and much more in the data model section of the reference. Cute puzzles like a __hash__ returning a random value can be left for stackoverflow. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 12:39:25 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 16:39:25 +0000 Subject: [issue24413] Inconsistent behavior between set and dict_keys/dict_items: for non-iterable object x, set().__or__(x) returns NotImplemented, but {}.keys().__or__(x) raises TypeError In-Reply-To: <1433827977.01.0.296186023212.issue24413@psf.upfronthosting.co.za> Message-ID: <1566491965.9.0.462596914763.issue24413@roundup.psfhosted.org> Raymond Hettinger added the comment: > If this is only a theoretical problem, might it make sense > to just leave it as is? I'm fine with that. In the last four years, I'm the only one who ever noticed, so it doesn't appear to be a problem in practice. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 12:39:59 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 16:39:59 +0000 Subject: [issue14050] Tutorial, list.sort() and items comparability In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za> Message-ID: <1566491999.32.0.254590207866.issue14050@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset cb8de91dadf15925fb95069cb190398e1d485f56 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-14050: Note that not all data can be sorted (GH-15381) (GH-15395) https://github.com/python/cpython/commit/cb8de91dadf15925fb95069cb190398e1d485f56 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 12:40:18 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 16:40:18 +0000 Subject: [issue14050] Tutorial, list.sort() and items comparability In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za> Message-ID: <1566492018.2.0.376457941685.issue14050@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 Aug 22 13:22:32 2019 From: report at bugs.python.org (Mark Sapiro) Date: Thu, 22 Aug 2019 17:22:32 +0000 Subject: [issue37919] nntplib throws spurious NNTPProtocolError Message-ID: <1566494552.99.0.566197119137.issue37919@roundup.psfhosted.org> New submission from Mark Sapiro : This is really due to an nntp server bug, but here's the scenerio. A connection is opened to the server. An article is posted via the connection's post() method. The server responds to the article data with 240 Article posted but due to the server bug, if the message-id is long, this response comes on two lines as 240 Article posted The post() method reads only the first line and returns it. Then the connection's quit() method (or some other method) is called, and it sees the second line of the prior response as the server's response rather than the actual response, and raises NNTPProtocolError. Arguably, NNTPProtocolError is appropriate in this scenario, but if so, it should be raised by the post() method and not by a subsequent method. ---------- components: Library (Lib) messages: 350214 nosy: msapiro priority: normal severity: normal status: open title: nntplib throws spurious NNTPProtocolError versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 13:29:28 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 17:29:28 +0000 Subject: [issue30550] Document order-preserving dictionary output in json In-Reply-To: <1496396847.32.0.655591837652.issue30550@psf.upfronthosting.co.za> Message-ID: <1566494968.12.0.28522215126.issue30550@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +15105 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15397 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 13:48:14 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 17:48:14 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <1566496094.06.0.748663132541.issue28556@roundup.psfhosted.org> miss-islington added the comment: New changeset 8889627b53e1eea2e32590f1867fbb0b0fc7407f by Miss Islington (bot) (Ivan Levkivskyi) in branch 'master': bpo-28556: Add a regression test to typing (GH-15396) https://github.com/python/cpython/commit/8889627b53e1eea2e32590f1867fbb0b0fc7407f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 13:48:41 2019 From: report at bugs.python.org (Brett Cannon) Date: Thu, 22 Aug 2019 17:48:41 +0000 Subject: [issue37918] What about an enum for open() modes? In-Reply-To: <1566489249.72.0.0117548525062.issue37918@roundup.psfhosted.org> Message-ID: <1566496121.1.0.844841674959.issue37918@roundup.psfhosted.org> Change by Brett Cannon : ---------- priority: normal -> low type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 13:49:46 2019 From: report at bugs.python.org (George Zhang) Date: Thu, 22 Aug 2019 17:49:46 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566496186.17.0.720548076411.issue37902@roundup.psfhosted.org> George Zhang added the comment: Also, how should I get the new code coverage percentage (or should it be ignored for now)? I'm thinking of adding a few more tests that send invalid events which would raise KeyError but I don't think that this behaviour will be used (and it's not documented). Should it give a more specific error message? The test for multicall is only targeting the MultiCall class that gets returned. How should it check for any possible subclasses of it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 13:50:24 2019 From: report at bugs.python.org (Brett Cannon) Date: Thu, 22 Aug 2019 17:50:24 +0000 Subject: [issue37890] Modernize several tests in test_importlib In-Reply-To: <1566269296.72.0.828504709815.issue37890@roundup.psfhosted.org> Message-ID: <1566496224.53.0.661164017222.issue37890@roundup.psfhosted.org> Brett Cannon added the comment: I would just read through the other tests files under test_importlib to see how other tests were done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 13:52:13 2019 From: report at bugs.python.org (Brett Cannon) Date: Thu, 22 Aug 2019 17:52:13 +0000 Subject: [issue37660] Drop support for Aspen magic directories in venv's activate scripts In-Reply-To: <1563907142.04.0.0759083175795.issue37660@roundup.psfhosted.org> Message-ID: <1566496333.35.0.894520179201.issue37660@roundup.psfhosted.org> Brett Cannon added the comment: Fixed by issue37663. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 13:52:26 2019 From: report at bugs.python.org (Brett Cannon) Date: Thu, 22 Aug 2019 17:52:26 +0000 Subject: [issue37661] venv activation scripts erroneously check if __VENV_PROMPT__ is defined In-Reply-To: <1563909427.85.0.687567591149.issue37661@roundup.psfhosted.org> Message-ID: <1566496346.93.0.37096018317.issue37661@roundup.psfhosted.org> Brett Cannon added the comment: Fixed by issue37663. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 13:52:42 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 17:52:42 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <1566496362.94.0.33177109629.issue28556@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15106 pull_request: https://github.com/python/cpython/pull/15398 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 13:52:43 2019 From: report at bugs.python.org (Brett Cannon) Date: Thu, 22 Aug 2019 17:52:43 +0000 Subject: [issue37663] Making venv activation script prompts consistent In-Reply-To: <1563914466.51.0.723098783517.issue37663@roundup.psfhosted.org> Message-ID: <1566496363.49.0.152593379355.issue37663@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 Aug 22 14:11:31 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 18:11:31 +0000 Subject: [issue28556] typing.py upgrades In-Reply-To: <1477756009.46.0.442279756181.issue28556@psf.upfronthosting.co.za> Message-ID: <1566497491.53.0.383341233.issue28556@roundup.psfhosted.org> miss-islington added the comment: New changeset 5fda09cc1ebcb364a660bc5a831ef8f6463d810b by Miss Islington (bot) in branch '3.8': bpo-28556: Add a regression test to typing (GH-15396) https://github.com/python/cpython/commit/5fda09cc1ebcb364a660bc5a831ef8f6463d810b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 14:20:41 2019 From: report at bugs.python.org (Cameron Trando) Date: Thu, 22 Aug 2019 18:20:41 +0000 Subject: [issue37920] Support subscripting os.PathLike and make it valid at runtime Message-ID: <1566498041.58.0.919656436902.issue37920@roundup.psfhosted.org> New submission from Cameron Trando : Currently os.PathLike[str] causes a runtime error; however, typeshed sees it as valid and mypy does not throw any errors on it. mypy treats it as os.PathLike[AnyStr] I already filed a bug on typeshed, see https://github.com/python/typeshed/issues/3202 And since mypy interprets it as useful, cpython should try and support it as well. ---------- messages: 350221 nosy: Cameron Trando priority: normal severity: normal status: open title: Support subscripting os.PathLike and make it valid at runtime type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 14:21:04 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 22 Aug 2019 18:21:04 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566498064.13.0.2551267711.issue37902@roundup.psfhosted.org> Terry J. Reedy added the comment: 'mousescroll' was not exact because the mouse is also used to scroll with the scrollbar. 'handlescroll' is worse. 'wheelscroll' seems awkward. 'scrollwheel' (scroll with the mouse wheel) is specific. At least in idlelib, event handlers are routinely called something_event, so use 'wheel_event'. Pressing the wheel is a Button-3 event (there used to be 3-button mice before wheeels) and a handler for that would be 'button3_event' or 'button3_press_event'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 14:22:03 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 22 Aug 2019 18:22:03 +0000 Subject: [issue37902] Add scrolling for IDLE browsers In-Reply-To: <1566352480.43.0.51909437022.issue37902@roundup.psfhosted.org> Message-ID: <1566498123.59.0.586282936434.issue37902@roundup.psfhosted.org> Terry J. Reedy added the comment: Don't worry more about tests until I look at what you have done already. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 14:37:15 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 18:37:15 +0000 Subject: [issue35654] Remove 'guarantee' that sorting only relies on __lt__ from sorting howto In-Reply-To: <1546551341.08.0.0908752668479.issue35654@roundup.psfhosted.org> Message-ID: <1566499035.36.0.539199703341.issue35654@roundup.psfhosted.org> Raymond Hettinger added the comment: > Well, if this is indeed by design (and I missed the > list.sort() reference) then I agree the HOWTO should not be changed It is in fact by design :-) ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 14:39:40 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 18:39:40 +0000 Subject: [issue34302] Avoid inefficient way to find start point in deque.index In-Reply-To: <1533090665.19.0.56676864532.issue34302@psf.upfronthosting.co.za> Message-ID: <1566499180.43.0.687044590263.issue34302@roundup.psfhosted.org> Raymond Hettinger added the comment: It looks like deque.index() now has a fast searcher. ---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 14:43:05 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 22 Aug 2019 18:43:05 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566499385.22.0.00700538246401.issue37915@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- nosy: +lukasz.langa priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 14:55:16 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 18:55:16 +0000 Subject: [issue11846] Remove non-guaranteed implementation details from docs. In-Reply-To: <1302815567.28.0.789640613127.issue11846@psf.upfronthosting.co.za> Message-ID: <1566500116.09.0.227421182964.issue11846@roundup.psfhosted.org> Raymond Hettinger added the comment: The current wording seems to have sufficed for users of the C API. Also, it is an implementation detail subject to change. Discussions on being able to mutate anything in C are covered in the ctypes module. ---------- resolution: accepted -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 15:24:31 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 19:24:31 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566501871.5.0.311763778949.issue37915@roundup.psfhosted.org> miss-islington added the comment: New changeset 4be11c009abe88175fa164b45e4838e7267dfa97 by Miss Islington (bot) (Pablo Galindo) in branch 'master': bpo-37915: Fix comparison between tzinfo objects and timezone objects (GH-15390) https://github.com/python/cpython/commit/4be11c009abe88175fa164b45e4838e7267dfa97 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 15:24:36 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 19:24:36 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566501876.59.0.201821697016.issue37915@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15107 pull_request: https://github.com/python/cpython/pull/15399 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 15:26:05 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 22 Aug 2019 19:26:05 +0000 Subject: [issue37920] Support subscripting os.PathLike and make it valid at runtime In-Reply-To: <1566498041.58.0.919656436902.issue37920@roundup.psfhosted.org> Message-ID: <1566501965.17.0.92564490061.issue37920@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +gvanrossum, levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 15:34:30 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 22 Aug 2019 19:34:30 +0000 Subject: [issue37920] Support subscripting os.PathLike and make it valid at runtime In-Reply-To: <1566498041.58.0.919656436902.issue37920@roundup.psfhosted.org> Message-ID: <1566502470.17.0.966213490553.issue37920@roundup.psfhosted.org> Guido van Rossum added the comment: Making an existing stdlib class generic has to be considered carefully, otherwise it may break backward compatibility. As I wrote in the typeshed issue, I actually think the status quo is fine. But I'd like to hear you out about how it causes problems in VS Code (that can't be fixed by adapting VC Code to reality). ---------- versions: +Python 3.9 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 15:37:49 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Thu, 22 Aug 2019 19:37:49 +0000 Subject: [issue37920] Support subscripting os.PathLike and make it valid at runtime In-Reply-To: <1566498041.58.0.919656436902.issue37920@roundup.psfhosted.org> Message-ID: <1566502669.43.0.233498637375.issue37920@roundup.psfhosted.org> Ivan Levkivskyi added the comment: There is an (old) similar proposal https://github.com/python/typing/issues/402 btw. Taking into account that this can be made only in 3.9, what is the benefit over ``from __future__ import annotations`` (that one can use already) do you see? IMO there are only rare cases of type aliases and base classes, so I don't see much benefit. Also making it generic will require importing ``typing`` from ``os`` which may make it slower to import (``typing`` is a really heavy module, in particular because it imports many other modules). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 16:19:19 2019 From: report at bugs.python.org (Cameron Trando) Date: Thu, 22 Aug 2019 20:19:19 +0000 Subject: [issue37920] Support subscripting os.PathLike and make it valid at runtime In-Reply-To: <1566498041.58.0.919656436902.issue37920@roundup.psfhosted.org> Message-ID: <1566505159.51.0.726468984167.issue37920@roundup.psfhosted.org> Cameron Trando added the comment: What happened is that we have a hard time analyzing PathLike because in the pathlib stub they use PathLike[str], so when we try to analyze Path which inherits from PathLike[str], because PathLike is not generic, then we think it's an instance of an object and don't inherit from it. That means Path has incorrect bases. Previously we assumed we only had to special case typing so we will special case PathLike as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 17:14:36 2019 From: report at bugs.python.org (Pierre-Jean Grenier) Date: Thu, 22 Aug 2019 21:14:36 +0000 Subject: [issue37921] Improve zipfile: add support for symlinks Message-ID: <1566508476.42.0.582332769766.issue37921@roundup.psfhosted.org> New submission from Pierre-Jean Grenier : The module tarfile contains some methods for knowing whether an archive member is a regular file/a directory/a symlink. Apart from an "is_dir()" method, there was nothing alike in the zipfile module. For an on-going project, I needed to know whether an archive member was a symlink or not, to prevent zip symlinks attacks. I thought this could be of used for other people, given I struggled a little to find a way of saying if an archive member is a symlink or not. This is why I think adding support for symlinks in the zipfile module could be a good idea. ---------- components: Library (Lib) messages: 350231 nosy: zaphodef priority: normal severity: normal status: open title: Improve zipfile: add support for symlinks type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 17:16:39 2019 From: report at bugs.python.org (Pierre-Jean Grenier) Date: Thu, 22 Aug 2019 21:16:39 +0000 Subject: [issue37921] Improve zipfile: add support for symlinks In-Reply-To: <1566508476.42.0.582332769766.issue37921@roundup.psfhosted.org> Message-ID: <1566508599.12.0.799218666754.issue37921@roundup.psfhosted.org> Change by Pierre-Jean Grenier : ---------- keywords: +patch pull_requests: +15108 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15401 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 17:47:47 2019 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 22 Aug 2019 21:47:47 +0000 Subject: [issue37920] Support subscripting os.PathLike and make it valid at runtime In-Reply-To: <1566498041.58.0.919656436902.issue37920@roundup.psfhosted.org> Message-ID: <1566510467.89.0.162368667124.issue37920@roundup.psfhosted.org> Guido van Rossum added the comment: Sounds like you are mixing up analyzing .pyi and .py files. Anyway, let's not do this. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 18:12:36 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 22 Aug 2019 22:12:36 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566511956.69.0.416637676571.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: > This is an issue when the standard handles are inherited or duplicated to a grandchild process, and so on. In the case of Popen(sys.executable), the system is duplicating the standard handles implicitly because sys.executable is a console process (assuming it's python[_d].exe), among other criteria. An additional reference on the write side prevents the pipe from closing. fh.read() in the grandparent won't return as long as there's a writer that could potentially write more data. Is there a way to workaround that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 18:14:47 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 22:14:47 +0000 Subject: [issue30550] Document order-preserving dictionary output in json In-Reply-To: <1496396847.32.0.655591837652.issue30550@psf.upfronthosting.co.za> Message-ID: <1566512087.51.0.985933490943.issue30550@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 657008ea0336ff4f275ed3f0c2b6dd2e52de2bba by Raymond Hettinger in branch 'master': bpo-30550: Clarify JSON ordering guarantees (GH-15397) https://github.com/python/cpython/commit/657008ea0336ff4f275ed3f0c2b6dd2e52de2bba ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 18:15:49 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 22 Aug 2019 22:15:49 +0000 Subject: [issue30550] Document order-preserving dictionary output in json In-Reply-To: <1496396847.32.0.655591837652.issue30550@psf.upfronthosting.co.za> Message-ID: <1566512149.78.0.916811734951.issue30550@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15110 pull_request: https://github.com/python/cpython/pull/15403 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 18:46:07 2019 From: report at bugs.python.org (Leonard Truong) Date: Thu, 22 Aug 2019 22:46:07 +0000 Subject: [issue37922] inspect.getsource returns wrong class definition when multiple class definitions share the same name (but are defined in different scopes) Message-ID: <1566513967.26.0.232695535045.issue37922@roundup.psfhosted.org> New submission from Leonard Truong : Here's a case where `inspect.getsource` returns the wrong class definition when a file contains multiple class definitions with the same name. This pattern is valid runtime behavior when the class definitions are inside different scopes (e.g. a factory pattern where classes are defined and returned inside a function). ``` import inspect def foo0(): class Foo: x = 4 return Foo def foo1(): class Foo: x = 5 return Foo print(inspect.getsource(foo1())) print(foo1().x) print(foo0().x) ``` Running this file produces ``` ? python inspect-getsource-issue.py class Foo: x = 4 5 4 ``` ---------- components: Library (Lib) files: inspect-getsource-issue.py messages: 350235 nosy: lennyt priority: normal severity: normal status: open title: inspect.getsource returns wrong class definition when multiple class definitions share the same name (but are defined in different scopes) versions: Python 3.7 Added file: https://bugs.python.org/file48557/inspect-getsource-issue.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 18:49:08 2019 From: report at bugs.python.org (Leonard Truong) Date: Thu, 22 Aug 2019 22:49:08 +0000 Subject: [issue37922] inspect.getsource returns wrong class definition when multiple class definitions share the same name (but are defined in different scopes) In-Reply-To: <1566513967.26.0.232695535045.issue37922@roundup.psfhosted.org> Message-ID: <1566514148.68.0.251649538992.issue37922@roundup.psfhosted.org> Leonard Truong added the comment: Turns out this is a documented issue in the source code: https://github.com/python/cpython/blob/3.7/Lib/inspect.py#L794-L796 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 18:50:37 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 22:50:37 +0000 Subject: [issue30550] Document order-preserving dictionary output in json In-Reply-To: <1496396847.32.0.655591837652.issue30550@psf.upfronthosting.co.za> Message-ID: <1566514237.46.0.407193975273.issue30550@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 4a40498ea96a3c606952712c7951b2ea4ab258e4 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-30550: Clarify JSON ordering guarantees (GH-15397) (GH-15403) https://github.com/python/cpython/commit/4a40498ea96a3c606952712c7951b2ea4ab258e4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 18:51:19 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 22:51:19 +0000 Subject: [issue30550] Document order-preserving dictionary output in json In-Reply-To: <1496396847.32.0.655591837652.issue30550@psf.upfronthosting.co.za> Message-ID: <1566514279.65.0.788097863884.issue30550@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 Aug 22 18:57:54 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 22:57:54 +0000 Subject: [issue26589] Add HTTP Response code 451 In-Reply-To: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za> Message-ID: <1566514674.49.0.0932727345889.issue26589@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 19:07:45 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 23:07:45 +0000 Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used. In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za> Message-ID: <1566515265.01.0.10524742458.issue24726@roundup.psfhosted.org> Raymond Hettinger added the comment: There may still be some holes still remaining in OrderedDict but it doesn't seem to have been relevant in practice and will become even less so now that regular dicts are ordered and compact. If an issue does are arise with someone setting OrderedDict values via dict.__setitem__ we should probably just document "don't do that" rather than performing brain surgery on the current implementation which was known in advance to be vulnerable to exactly this sort of trickery. If there are no objections, I recommend closing this as out-of-date. IMO this would be better than risking introducing new problems are getting the C version further out of sync with the Python version or altering how existing code is working. ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 19:09:01 2019 From: report at bugs.python.org (Caleb Donovick) Date: Thu, 22 Aug 2019 23:09:01 +0000 Subject: [issue37922] inspect.getsource returns wrong class definition when multiple class definitions share the same name (but are defined in different scopes) In-Reply-To: <1566513967.26.0.232695535045.issue37922@roundup.psfhosted.org> Message-ID: <1566515341.72.0.274679666308.issue37922@roundup.psfhosted.org> Change by Caleb Donovick : ---------- nosy: +donovick _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 19:12:26 2019 From: report at bugs.python.org (Kyle Stanley) Date: Thu, 22 Aug 2019 23:12:26 +0000 Subject: [issue37890] Modernize several tests in test_importlib In-Reply-To: <1566269296.72.0.828504709815.issue37890@roundup.psfhosted.org> Message-ID: <1566515546.35.0.338522592906.issue37890@roundup.psfhosted.org> Kyle Stanley added the comment: > I would just read through the other tests files under test_importlib to see how other tests were done. Okay, I'll start with that and report back with any ideas for potential changes to test_pkg_import. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 19:15:20 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 23:15:20 +0000 Subject: [issue19441] itertools.tee improve documentation In-Reply-To: <1383087333.66.0.191656186181.issue19441@psf.upfronthosting.co.za> Message-ID: <1566515720.62.0.2215881475.issue19441@roundup.psfhosted.org> Raymond Hettinger added the comment: This is out of date. The docs currently have: ''' Once :func:`tee` has made a split, the original *iterable* should not be used anywhere else; otherwise, the *iterable* could get advanced without the tee objects being informed. ''' ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 19:21:26 2019 From: report at bugs.python.org (Caleb Donovick) Date: Thu, 22 Aug 2019 23:21:26 +0000 Subject: [issue37922] inspect.getsource returns wrong class definition when multiple class definitions share the same name (but are defined in different scopes) In-Reply-To: <1566513967.26.0.232695535045.issue37922@roundup.psfhosted.org> Message-ID: <1566516086.24.0.472938472188.issue37922@roundup.psfhosted.org> Caleb Donovick added the comment: I think findsource could be made more robust by using __qualname__ if it available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 19:30:48 2019 From: report at bugs.python.org (Marco Sulla) Date: Thu, 22 Aug 2019 23:30:48 +0000 Subject: [issue37792] xml.etree.ElementTree.Element.__eq__ does compare only objects identity In-Reply-To: <1565258224.48.0.98423013878.issue37792@roundup.psfhosted.org> Message-ID: <1566516648.01.0.113290412635.issue37792@roundup.psfhosted.org> Marco Sulla added the comment: Thanks, but telling the truth: 1. I just not use SubElement, even if it's more convenient. I just create an Element and I append to the parent one. It's much more clear IMHO 2. I do not use `fromstring` and all its friends. It was just a suggestion 3. I already copy/pasted from SO a function that serialize the Element. I do not want to waste time to do something that will be not used as `Element.__eq__()` implementation, as IMHO should be. See ya. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 19:36:26 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 23:36:26 +0000 Subject: [issue12634] Random Remarks in class documentation In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za> Message-ID: <1566516986.77.0.86566174871.issue12634@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +15111 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15406 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 19:37:13 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 23:37:13 +0000 Subject: [issue12634] Random Remarks in class documentation In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za> Message-ID: <1566517033.29.0.589334845945.issue12634@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 19:39:54 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 22 Aug 2019 23:39:54 +0000 Subject: [issue27561] Warn against subclassing builtins, and overriding their methods In-Reply-To: <1468848651.49.0.804648096873.issue27561@psf.upfronthosting.co.za> Message-ID: <1566517194.09.0.983083660555.issue27561@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 20:19:44 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 00:19:44 +0000 Subject: [issue24724] Element.findall documentation misleading In-Reply-To: <1437881713.88.0.256447477825.issue24724@psf.upfronthosting.co.za> Message-ID: <1566519584.87.0.938126578859.issue24724@roundup.psfhosted.org> Raymond Hettinger added the comment: > Issue is closed as far as I'm concerned Me too. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 22:14:06 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 23 Aug 2019 02:14:06 +0000 Subject: [issue37922] inspect.getsource returns wrong class definition when multiple class definitions share the same name (but are defined in different scopes) In-Reply-To: <1566513967.26.0.232695535045.issue37922@roundup.psfhosted.org> Message-ID: <1566526446.71.0.12126319727.issue37922@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This looks like a duplicate of https://bugs.python.org/issue35113 . I have created a PR for the issue but didn't have time to debug the Windows issue. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 22:14:53 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 02:14:53 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566526493.4.0.32214371704.issue37884@roundup.psfhosted.org> Raymond Hettinger added the comment: [Mark] > I'm with Raymond here; I don't think this change is > desirable for the math module, either with or without > the leading underscore in the name. [Jeroen] > May I propose PR 15327 as alternative? I'll take a look soonish. Since it has its own BPO, I'll go ahead and close this. FWIW, the entire point of us having recently added as_integer_ratio() methods to so many concrete classes is to avoid the need for helper functions in favor of a simple try/except around a single call. Please don't try to code around that solution. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 22 23:04:25 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 23 Aug 2019 03:04:25 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566529465.76.0.406964876923.issue37531@roundup.psfhosted.org> Eryk Sun added the comment: > Is there a way to workaround that? For Windows, subprocess could have a _read_all(file) method that special cases a pipe. The read loop for a pipe would check whether the child has exited. Then call _winapi.PeekNamedPipe on the handle (from get_osfhandle), and do a raw read of the available bytes. If the child has exited or PeekNamedPipe fails (EPIPE), then break, join the partial reads, decode and translate newlines if it's text mode, and return. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 00:42:18 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 04:42:18 +0000 Subject: [issue30826] More details in reference 'Looping through a list in Python and modifying it' In-Reply-To: <1498969328.51.0.74139016573.issue30826@psf.upfronthosting.co.za> Message-ID: <1566535338.1.0.855080431627.issue30826@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +15112 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15407 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 01:15:37 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 05:15:37 +0000 Subject: [issue14112] tutorial intro talks of "shallow copy" concept without explanation In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za> Message-ID: <1566537337.92.0.0997357707677.issue14112@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +15113 pull_request: https://github.com/python/cpython/pull/15408 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 01:29:14 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 05:29:14 +0000 Subject: [issue25898] Check for subsequence inside a sequence In-Reply-To: <1450403111.33.0.306166289689.issue25898@psf.upfronthosting.co.za> Message-ID: <1566538154.86.0.698796086736.issue25898@roundup.psfhosted.org> Raymond Hettinger added the comment: > If I were trying to channel Raymond I'd suggest posting the > python as a recipe and see if there is uptake. However, I > could be wrong and he might be interested. (I can't say > that I've ever needed this check myself.) Yes, exactly :-) Sebastian, thanks for the suggestion. I am going to decline this for collections and itertools based on the relative infrequency of need (for us, it usually only comes up in the context of strings). FWIW, there may be algorithmically more advanced techniques that might be worth looking into: knuth-morris-pratt, rabin-karp, etc. Please do post this to the Python Package Index or someother place where people can get to it if the need arises. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 01:38:17 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 05:38:17 +0000 Subject: [issue29330] __slots__ needs documentation In-Reply-To: <1484865040.1.0.923136956691.issue29330@psf.upfronthosting.co.za> Message-ID: <1566538697.89.0.919409247839.issue29330@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 01:44:01 2019 From: report at bugs.python.org (dmontague) Date: Fri, 23 Aug 2019 05:44:01 +0000 Subject: [issue37923] Combining typing.get_type_hints and inspect.signature Message-ID: <1566539041.61.0.905400107157.issue37923@roundup.psfhosted.org> New submission from dmontague : I am trying to obtain the output of `inspect.signature`, except with string-valued annotations converted to resolved type hints, similarly to `typing.get_type_hints`. Is there a good way to do this currently? If not, might this be a good fit for the standard library? --------------- The straightforward way I see to attempt this would be to call both `typing.get_type_hints` and `inspect.signature` on the callable, and then "merge" the results. However, as far as I can tell, that only works if the provided callable is a function or method (i.e., not a type or a callable class instance). As an example, if I have an instance of a class with a `__call__` method, and the class was defined in a module with `from __future__ import annotations`, then calling `inspect.signature` on the instances will only return an `inspect.Signature` with type-unaware strings as the annotations for each `inspect.Parameter`. On the other hand, calling `get_type_hints` on the instance will return type hints for the class, rather than for its `__call__` method. I wouldn't mind manually handling an edge case or two, but the logic used by `inspect.signature` to determine which function will be called seems relatively involved, and so I would ideally like to leverage this same logic while obtaining the type-resolved version signature for the callable. ---------- messages: 350248 nosy: dmontague, levkivskyi priority: normal severity: normal status: open title: Combining typing.get_type_hints and inspect.signature type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 01:50:28 2019 From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=) Date: Fri, 23 Aug 2019 05:50:28 +0000 Subject: [issue37924] Embedding Python in Another Application: Compiling under Unix misses the --embed flag Message-ID: <1566539428.8.0.420349967118.issue37924@roundup.psfhosted.org> New submission from Miro Hron?ok : Based on changes in https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build I belive we should document the python3.8-config --embed flag in https://docs.python.org/3.8/extending/embedding.html#compiling-and-linking-under-unix-like-systems ---------- assignee: docs at python components: Documentation messages: 350249 nosy: docs at python, hroncok, vstinner priority: normal severity: normal status: open title: Embedding Python in Another Application: Compiling under Unix misses the --embed flag versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 01:52:58 2019 From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=) Date: Fri, 23 Aug 2019 05:52:58 +0000 Subject: [issue37925] --embed not included in python3.8-config usage/--help Message-ID: <1566539578.53.0.511767507414.issue37925@roundup.psfhosted.org> New submission from Miro Hron?ok : Based on changes in https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build I think that the usage string of python3.8-config should also contain --embed. Actual output: $ python3.8-config Usage: /usr/bin/python3.8-x86_64-config --prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir Expected output: $ python3.8-config Usage: /usr/bin/python3.8-x86_64-config --prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--embed|--extension-suffix|--help|--abiflags|--configdir ---------- components: Extension Modules messages: 350250 nosy: hroncok, vstinner priority: normal severity: normal status: open title: --embed not included in python3.8-config usage/--help versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 02:24:40 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 06:24:40 +0000 Subject: [issue32621] Problem of consistency in collection.abc documentation In-Reply-To: <1516631316.64.0.467229070634.issue32621@psf.upfronthosting.co.za> Message-ID: <1566541480.98.0.608375560227.issue32621@roundup.psfhosted.org> Raymond Hettinger added the comment: The table is correct. See the interactive session below for confirmation. I think the source of your confusion is that some of the more complex ABCs are able to generate some of the required methods from the ones that are listed (for example, Mapping is able to automatically create __contains__ from __getitem__, so the former is not listed as a required abstract method). >>> Container.__abstractmethods__ frozenset({'__contains__'}) >>> Hashable.__abstractmethods__ frozenset({'__hash__'}) >>> Iterable.__abstractmethods__ frozenset({'__iter__'}) >>> Reversible.__abstractmethods__ frozenset({'__reversed__', '__iter__'}) >>> Generator.__abstractmethods__ frozenset({'send', 'throw'}) >>> Sized.__abstractmethods__ frozenset({'__len__'}) >>> Callable.__abstractmethods__ frozenset({'__call__'}) >>> Collection.__abstractmethods__ frozenset({'__iter__', '__len__', '__contains__'}) >>> Sequence.__abstractmethods__ frozenset({'__getitem__', '__len__'}) >>> MutableSequence.__abstractmethods__ frozenset({'insert', '__getitem__', '__len__', '__delitem__', '__setitem__'}) >>> ByteString.__abstractmethods__ frozenset({'__getitem__', '__len__'}) >>> Set.__abstractmethods__ frozenset({'__iter__', '__len__', '__contains__'}) >>> MutableSet.__abstractmethods__ frozenset({'add', '__len__', '__iter__', 'discard', '__contains__'}) >>> Mapping.__abstractmethods__ frozenset({'__getitem__', '__iter__', '__len__'}) >>> MutableMapping.__abstractmethods__ frozenset({'__getitem__', '__len__', '__iter__', '__delitem__', '__setitem__'}) >>> MappingView.__abstractmethods__ frozenset() >>> ItemsView.__abstractmethods__ frozenset() >>> KeysView.__abstractmethods__ frozenset() >>> ValuesView.__abstractmethods__ frozenset() >>> Awaitable.__abstractmethods__ frozenset({'__await__'}) >>> Coroutine.__abstractmethods__ frozenset({'send', 'throw', '__await__'}) >>> AsyncIterable.__abstractmethods__ frozenset({'__aiter__'}) >>> AsyncIterator.__abstractmethods__ frozenset({'__anext__'}) >>> AsyncGenerator.__abstractmethods__ frozenset({'athrow', 'asend'}) ---------- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 02:27:17 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 06:27:17 +0000 Subject: [issue12634] Random Remarks in class documentation In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za> Message-ID: <1566541637.09.0.755204971772.issue12634@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15114 pull_request: https://github.com/python/cpython/pull/15409 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 02:27:25 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 06:27:25 +0000 Subject: [issue12634] Random Remarks in class documentation In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za> Message-ID: <1566541645.51.0.82031707162.issue12634@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 483ae0cf1dcf46f8b71c4bf32419dd138e908553 by Raymond Hettinger in branch 'master': bpo-12634: Clarify an awkward section of the tutorial (GH-15406) https://github.com/python/cpython/commit/483ae0cf1dcf46f8b71c4bf32419dd138e908553 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 02:44:22 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 06:44:22 +0000 Subject: [issue30826] More details in reference 'Looping through a list in Python and modifying it' In-Reply-To: <1498969328.51.0.74139016573.issue30826@psf.upfronthosting.co.za> Message-ID: <1566542662.61.0.487097150251.issue30826@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 6fcb6cfb139ade1aac6dbee0b18ca72b18cbe0d2 by Raymond Hettinger in branch 'master': bpo-30826: Improve control flow examples (GH-15407) https://github.com/python/cpython/commit/6fcb6cfb139ade1aac6dbee0b18ca72b18cbe0d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 02:44:29 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 06:44:29 +0000 Subject: [issue30826] More details in reference 'Looping through a list in Python and modifying it' In-Reply-To: <1498969328.51.0.74139016573.issue30826@psf.upfronthosting.co.za> Message-ID: <1566542669.68.0.443229904815.issue30826@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15115 pull_request: https://github.com/python/cpython/pull/15410 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 02:45:59 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 06:45:59 +0000 Subject: [issue12634] Random Remarks in class documentation In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za> Message-ID: <1566542759.86.0.532022645836.issue12634@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset f6a7f5bc50f4267cfb7fe0c4ea16d5359c009cbd by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-12634: Clarify an awkward section of the tutorial (GH-15406) (GH-15409) https://github.com/python/cpython/commit/f6a7f5bc50f4267cfb7fe0c4ea16d5359c009cbd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 02:46:25 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 06:46:25 +0000 Subject: [issue12634] Random Remarks in class documentation In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za> Message-ID: <1566542785.52.0.222691172949.issue12634@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 02:52:18 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 06:52:18 +0000 Subject: [issue30826] More details in reference 'Looping through a list in Python and modifying it' In-Reply-To: <1498969328.51.0.74139016573.issue30826@psf.upfronthosting.co.za> Message-ID: <1566543138.02.0.0106079497743.issue30826@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset b6341e676af2f58f3ad9b51a0d2fb7db5a3428e3 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-30826: Improve control flow examples (GH-15407) (GH-15410) https://github.com/python/cpython/commit/b6341e676af2f58f3ad9b51a0d2fb7db5a3428e3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 02:52:47 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 06:52:47 +0000 Subject: [issue30826] More details in reference 'Looping through a list in Python and modifying it' In-Reply-To: <1498969328.51.0.74139016573.issue30826@psf.upfronthosting.co.za> Message-ID: <1566543167.41.0.475204336239.issue30826@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 02:55:18 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 06:55:18 +0000 Subject: [issue37439] Add random.binomialvariate() In-Reply-To: <1561714089.16.0.904652961331.issue37439@roundup.psfhosted.org> Message-ID: <1566543318.25.0.334860751295.issue37439@roundup.psfhosted.org> Raymond Hettinger added the comment: [Avi] > Shall I update the PR? Yes, please. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 02:57:22 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 06:57:22 +0000 Subject: [issue37206] Incorrect application of Argument Clinic to dict.pop() In-Reply-To: <1560019685.35.0.640301237908.issue37206@roundup.psfhosted.org> Message-ID: <1566543442.69.0.667870294481.issue37206@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 02:59:20 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 06:59:20 +0000 Subject: [issue37454] Clarify docs for math.log1p() In-Reply-To: <1561933178.32.0.315765765879.issue37454@roundup.psfhosted.org> Message-ID: <1566543560.58.0.891336630238.issue37454@roundup.psfhosted.org> Raymond Hettinger added the comment: Sometimes you guys make me feel dumb as a rock. Sorry for the distraction. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 03:01:30 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 07:01:30 +0000 Subject: [issue13397] Option for XMLRPC clients to automatically transform Fault exceptions into standard exceptions In-Reply-To: <1321218030.66.0.0560016220773.issue13397@psf.upfronthosting.co.za> Message-ID: <1566543690.48.0.381409182104.issue13397@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> rejected stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 03:04:00 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 07:04:00 +0000 Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used. In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za> Message-ID: <1566543840.7.0.374100016311.issue24726@roundup.psfhosted.org> Raymond Hettinger added the comment: See also: https://bugs.python.org/msg131551 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 03:18:27 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 07:18:27 +0000 Subject: [issue17642] IDLE add font resizing hot keys and wheel In-Reply-To: <1365228385.87.0.236246362772.issue17642@psf.upfronthosting.co.za> Message-ID: <1566544707.74.0.413366072743.issue17642@roundup.psfhosted.org> Raymond Hettinger added the comment: > Key or wheel patches will probably be 3.6 only. I still have hopes that this will happen. Am I correct in thinking that it wouldn't be difficult to map CMD-plus and CMD-minus (or for Windows Cntl-plus and Cntl-minus) to a function that increases or decreases the font-size without having to manually go to Preferences/FontsAndTabs? ---------- versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 03:33:49 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 07:33:49 +0000 Subject: [issue24533] Increased Test Coverage for Lib/random.py In-Reply-To: <1435602887.43.0.963223854079.issue24533@psf.upfronthosting.co.za> Message-ID: <1566545629.68.0.92412400487.issue24533@roundup.psfhosted.org> Raymond Hettinger added the comment: The test code now includes this: def test_shuffle_random_argument(self): # Test random argument to shuffle. shuffle = self.gen.shuffle mock_random = unittest.mock.Mock(return_value=0.5) seq = bytearray(b'abcdefghijk') shuffle(seq, mock_random) mock_random.assert_called_with() Thank you for the suggestion. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 03:36:47 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 07:36:47 +0000 Subject: [issue14112] tutorial intro talks of "shallow copy" concept without explanation In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za> Message-ID: <1566545807.27.0.53149457403.issue14112@roundup.psfhosted.org> Raymond Hettinger added the comment: How about we just like "shallow copy" to the copy module docs. That way, a person can follow-up with more detail if they're interested, yet still can read-on without interruption if they choose (this entry occurs *very* early in the tutorial). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 03:39:09 2019 From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=) Date: Fri, 23 Aug 2019 07:39:09 +0000 Subject: [issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function Message-ID: <1566545949.45.0.201062291719.issue37926@roundup.psfhosted.org> New submission from Miro Hron?ok : There is a regression between Python 3.7 and 3.8 when using PySys_SetArgvEx(0, NULL, 0). Consider this example: #include int main() { Py_Initialize(); PySys_SetArgvEx(0, NULL, 0); /* HERE */ PyRun_SimpleString("from time import time,ctime\n" "print('Today is', ctime(time()))\n"); Py_FinalizeEx(); return 0; } This works in 3.7 but no longer does in 3.8: $ gcc $(python3.7-config --cflags --ldflags) example.c $ ./a.out Today is Fri Aug 23 07:59:52 2019 $ gcc $(python3.8-config --cflags --ldflags --embed) example.c $ ./a.out Fatal Python error: no mem for sys.argv SystemError: /builddir/build/BUILD/Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function Current thread 0x00007f12c78b9740 (most recent call first): Aborted (core dumped) The documentation https://docs.python.org/3/c-api/init.html#c.PySys_SetArgvEx explicitly mentions passing 0 to PySys_SetArgvEx: "if argc is 0..." So I guess this is not something you shouldn't do. ---------- components: Extension Modules messages: 350262 nosy: hroncok, vstinner priority: normal severity: normal status: open title: regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 03:47:11 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 23 Aug 2019 07:47:11 +0000 Subject: [issue33830] Error in the output of one example in the httplib docs In-Reply-To: <1528713903.44.0.592728768989.issue33830@psf.upfronthosting.co.za> Message-ID: <1566546431.01.0.268830655258.issue33830@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Closing this since PRs have been merged. Thanks Aifu LIU for the report. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 03:51:55 2019 From: report at bugs.python.org (Talha Ahmed) Date: Fri, 23 Aug 2019 07:51:55 +0000 Subject: [issue37927] No Instantiation Restrictions for AbstractBaseClasses derived from builtin types Message-ID: <1566546715.82.0.869555987333.issue37927@roundup.psfhosted.org> New submission from Talha Ahmed : I have been experimenting a little with the `abc` module in python. A la >>> import abc In the normal case you expect your ABC class to not be instantiated if it contains an unimplemented `abstractmethod`. You know like as follows: >>> class MyClass(metaclass=abc.ABCMeta): ... @abc.abstractmethod ... def mymethod(self): ... return -1 ... >>> MyClass() Traceback (most recent call last): File "", line 1, in TypeError: Can't instantiate abstract class MyClass with abstract methods mymethod OR for any derived Class. It all seems to work fine until you inherit from something ... say `dict` or `list` as in the following: >>> class YourClass(list, metaclass=abc.ABCMeta): ... @abc.abstractmethod ... def yourmethod(self): ... return -1 ... >>> YourClass() [] This is inconsistent because `type` is supposed to be the primary factory. >>> type(abc.ABCMeta) >>> type(list) Why is the check for `__abstractmethods__` only implemented for `object_new` and not for other built-in types? ---------- components: Interpreter Core messages: 350264 nosy: Talha Ahmed priority: normal severity: normal status: open title: No Instantiation Restrictions for AbstractBaseClasses derived from builtin types type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 03:53:59 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 23 Aug 2019 07:53:59 +0000 Subject: [issue37927] No Instantiation Restrictions for AbstractBaseClasses derived from builtin types In-Reply-To: <1566546715.82.0.869555987333.issue37927@roundup.psfhosted.org> Message-ID: <1566546839.65.0.822901191316.issue37927@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 03:58:39 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Fri, 23 Aug 2019 07:58:39 +0000 Subject: [issue37927] No Instantiation Restrictions for AbstractBaseClasses derived from builtin types In-Reply-To: <1566546715.82.0.869555987333.issue37927@roundup.psfhosted.org> Message-ID: <1566547119.05.0.0188522536205.issue37927@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: This looks like a duplicate of issue35362. I would prefer closing one of them to keep the discussion in one place. This looks like a variant of this issue : issue35063 ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 04:06:41 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 08:06:41 +0000 Subject: [issue26589] Add HTTP Response code 451 In-Reply-To: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za> Message-ID: <1566547601.07.0.579944098024.issue26589@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +15116 pull_request: https://github.com/python/cpython/pull/15413 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 04:12:30 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 08:12:30 +0000 Subject: [issue26589] Add HTTP Response code 451 In-Reply-To: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za> Message-ID: <1566547950.61.0.31273067563.issue26589@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 04:23:10 2019 From: report at bugs.python.org (Kyle Stanley) Date: Fri, 23 Aug 2019 08:23:10 +0000 Subject: [issue37585] Comparing PyDictValues does not give expected results In-Reply-To: <1563019128.62.0.639495498673.issue37585@roundup.psfhosted.org> Message-ID: <1566548590.22.0.0106783436117.issue37585@roundup.psfhosted.org> Kyle Stanley added the comment: Reopening the issue for adding the documentation clarification, that comparing the values view of two dictionaries will always return false (as was suggested in the ML discussion https://mail.python.org/archives/list/python-dev at python.org/message/K3SYX4DER3WAOWGQ4SPKCKXSXLXTIVAQ/). A month ago, I opened to PR to add the clarification to the documentation for dict.values(): https://github.com/python/cpython/pull/14954/files. It probably went unnoticed because the issue had already been closed (which I hadn't realized at the time). ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 04:48:45 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 08:48:45 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566550125.72.0.888487121883.issue37915@roundup.psfhosted.org> miss-islington added the comment: New changeset 5c77730300c0358d7bebd2bb39ea5d10222a3d9a by Miss Islington (bot) in branch '3.8': bpo-37915: Fix comparison between tzinfo objects and timezone objects (GH-15390) https://github.com/python/cpython/commit/5c77730300c0358d7bebd2bb39ea5d10222a3d9a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 05:35:21 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 09:35:21 +0000 Subject: [issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function In-Reply-To: <1566545949.45.0.201062291719.issue37926@roundup.psfhosted.org> Message-ID: <1566552921.93.0.641877193911.issue37926@roundup.psfhosted.org> Change by STINNER Victor : ---------- keywords: +patch pull_requests: +15117 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15415 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 05:39:47 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 09:39:47 +0000 Subject: [issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function In-Reply-To: <1566545949.45.0.201062291719.issue37926@roundup.psfhosted.org> Message-ID: <1566553187.03.0.785369353582.issue37926@roundup.psfhosted.org> STINNER Victor added the comment: Oops, it's my fault! PR 15415 fix the crash. The regression was introduced by: commit 74f6568bbd3e70806ea3219e8bacb386ad802ccf Author: Victor Stinner Date: Fri Mar 15 15:08:05 2019 +0100 bpo-36301: Add _PyWstrList structure (GH-12343) Simplified change: - static wchar_t *empty_argv[1] = {L""}; + wchar_t* empty_argv[1] = {L""}; It's a deliberate change to not waste memory: PySys_SetArgvEx() (make_sys_argv()) is only called once, whereas static keeps the memory for the whole lifecycle of the process. But I didn't notice a subtle issue with memory allocated on the stack: the code works well with gcc -O0! The bug only triggers with gcc -O3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 05:54:56 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 23 Aug 2019 09:54:56 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566554096.71.0.0610880801069.issue37915@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- pull_requests: +15118 pull_request: https://github.com/python/cpython/pull/15417 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 06:00:53 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 10:00:53 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566554453.88.0.389760764868.issue37531@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15119 pull_request: https://github.com/python/cpython/pull/15419 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 06:04:19 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 10:04:19 +0000 Subject: [issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function In-Reply-To: <1566545949.45.0.201062291719.issue37926@roundup.psfhosted.org> Message-ID: <1566554659.99.0.999954847158.issue37926@roundup.psfhosted.org> STINNER Victor added the comment: New changeset c48682509dc49b43fe914fe6c502bc390345d1c2 by Victor Stinner in branch 'master': bpo-37926: Fix PySys_SetArgvEx(0, NULL, 0) crash (GH-15415) https://github.com/python/cpython/commit/c48682509dc49b43fe914fe6c502bc390345d1c2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 06:12:34 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 23 Aug 2019 10:12:34 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566555154.68.0.717173116158.issue37915@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: New changeset 1b1796df3a4292067a174faa11b1a852f79e98e3 by Pablo Galindo in branch '3.7': [3.7] bpo-37915: Fix comparison between tzinfo objects and timezone objects (GH-15390) (GH-15417) https://github.com/python/cpython/commit/1b1796df3a4292067a174faa11b1a852f79e98e3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 06:12:53 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 23 Aug 2019 10:12:53 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566555173.94.0.82356798082.issue37915@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +3.7regression -patch nosy: +ned.deily resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 06:19:28 2019 From: report at bugs.python.org (Ivan Levkivskyi) Date: Fri, 23 Aug 2019 10:19:28 +0000 Subject: [issue37923] Combining typing.get_type_hints and inspect.signature In-Reply-To: <1566539041.61.0.905400107157.issue37923@roundup.psfhosted.org> Message-ID: <1566555568.97.0.841920830976.issue37923@roundup.psfhosted.org> Ivan Levkivskyi added the comment: Somewhat related to https://bugs.python.org/issue37496 ---------- nosy: +eric.snow, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 06:21:02 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 10:21:02 +0000 Subject: [issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function In-Reply-To: <1566545949.45.0.201062291719.issue37926@roundup.psfhosted.org> Message-ID: <1566555662.83.0.370852052863.issue37926@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15120 pull_request: https://github.com/python/cpython/pull/15420 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 06:27:27 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 10:27:27 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566556047.37.0.111069123518.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 767434c39c8f3c6a8af1b3282d8382ccf809fe21 by Victor Stinner in branch 'master': bpo-37531: Fix regrtest _timedout() function on timeout (GH-15419) https://github.com/python/cpython/commit/767434c39c8f3c6a8af1b3282d8382ccf809fe21 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 06:41:28 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 10:41:28 +0000 Subject: [issue37928] test_glob.test_selflink() fails randomly on AMD64 Fedora Rawhide Clang Installed 3.x Message-ID: <1566556888.02.0.20425235487.issue37928@roundup.psfhosted.org> New submission from STINNER Victor : The test failed and then passed when re-run in verbose mode: https://buildbot.python.org/all/#/builders/188/builds/858 FAIL: test_selflink (test.test_glob.SymlinkLoopGlobTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.cstratak-fedora.installed/build/target/lib/python3.9/test/test_glob.py", line 311, in test_selflink self.assertIn(path, results) AssertionError: 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/' not found in {'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/', 'dir/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/link/'} ---------- components: Tests messages: 350273 nosy: vstinner priority: normal severity: normal status: open title: test_glob.test_selflink() fails randomly on AMD64 Fedora Rawhide Clang Installed 3.x versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 07:03:04 2019 From: report at bugs.python.org (Batuhan) Date: Fri, 23 Aug 2019 11:03:04 +0000 Subject: [issue37925] --embed not included in python3.8-config usage/--help In-Reply-To: <1566539578.53.0.511767507414.issue37925@roundup.psfhosted.org> Message-ID: <1566558184.95.0.795284801695.issue37925@roundup.psfhosted.org> Batuhan added the comment: I can work on this. ---------- nosy: +BTaskaya _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 07:22:20 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 11:22:20 +0000 Subject: [issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function In-Reply-To: <1566545949.45.0.201062291719.issue37926@roundup.psfhosted.org> Message-ID: <1566559340.14.0.125341494822.issue37926@roundup.psfhosted.org> STINNER Victor added the comment: New changeset ca9ae94a2aba35d94ac1ec081f9bcac3a13aebd3 by Victor Stinner in branch '3.8': bpo-37926: Fix PySys_SetArgvEx(0, NULL, 0) crash (GH-15415) (GH-15420) https://github.com/python/cpython/commit/ca9ae94a2aba35d94ac1ec081f9bcac3a13aebd3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 07:23:48 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 11:23:48 +0000 Subject: [issue37926] regression: PySys_SetArgvEx(0, NULL, 0): SystemError: Python-3.8.0b3/Objects/unicodeobject.c:2089: bad argument to internal function In-Reply-To: <1566545949.45.0.201062291719.issue37926@roundup.psfhosted.org> Message-ID: <1566559428.11.0.818264275827.issue37926@roundup.psfhosted.org> STINNER Victor added the comment: I tested my fix manually using example from msg350262 and gcc -O3 (./configure && make): I can reproduce the crash without the change, and I confirm that my change fix the crash. Thanks Miro for the bug report: the fix will be included in next Python 3.8 beta release. I fixed the bug in 3.8 and master branches (3.7 is not affected). ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 07:53:21 2019 From: report at bugs.python.org (Ned Deily) Date: Fri, 23 Aug 2019 11:53:21 +0000 Subject: [issue37915] Segfault in comparison between datetime.timezone.utc and pytz.utc In-Reply-To: <1566472719.5.0.285730751371.issue37915@roundup.psfhosted.org> Message-ID: <1566561201.45.0.737690152728.issue37915@roundup.psfhosted.org> Ned Deily added the comment: (Removing ?3.7regression? as the problematic change for 3.7 had not yet been released.) ---------- keywords: -3.7regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 08:47:51 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 12:47:51 +0000 Subject: [issue34521] Multiple tests (test_socket, test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer lengths, causing failures on FreeBSD CURRENT In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za> Message-ID: <1566564471.48.0.887155869245.issue34521@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15121 pull_request: https://github.com/python/cpython/pull/15422 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 08:50:01 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 12:50:01 +0000 Subject: [issue34521] Multiple tests (test_socket, test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer lengths, causing failures on FreeBSD CURRENT In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za> Message-ID: <1566564601.25.0.577763569681.issue34521@roundup.psfhosted.org> STINNER Victor added the comment: I am able to reproduce test_multiprocessing.test_fd_transfer() failure on the FreeBSD CURRENT buildbot: CURRENT-amd64% ./python -m test -m test_fd_transfer test_multiprocessing (...) Tests result: FAILURE I converted my msg330654 patch into PR 15422: I confirm that this PR fix test_fd_transfer() and test_large_fd_transfer() of test_multiprocessing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 08:50:32 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 12:50:32 +0000 Subject: [issue34521] Multiple tests (test_socket, test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer lengths, causing failures on FreeBSD CURRENT In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za> Message-ID: <1566564632.25.0.55046583766.issue34521@roundup.psfhosted.org> STINNER Victor added the comment: Note: I also wrote PR 15421 to remove temporary files created by these 2 tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 09:00:41 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 13:00:41 +0000 Subject: [issue34521] Multiple tests (test_socket, test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer lengths, causing failures on FreeBSD CURRENT In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za> Message-ID: <1566565241.39.0.928021823421.issue34521@roundup.psfhosted.org> STINNER Victor added the comment: New changeset c3642219090f2564c1790330cbf0ba31f19dcaf4 by Victor Stinner in branch '2.7': bpo-34521: Fix FD transfer in multiprocessing on FreeBSD (GH-15422) https://github.com/python/cpython/commit/c3642219090f2564c1790330cbf0ba31f19dcaf4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 09:27:44 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 23 Aug 2019 13:27:44 +0000 Subject: [issue37929] IDLE: OK sometimes fails to close configdialog Message-ID: <1566566864.85.0.308464800085.issue37929@roundup.psfhosted.org> New submission from Terry J. Reedy : If one opens configdialog when there is no Shell and then hits OK, the dialog fails to close. The following Squeezer-related traceback appears in associated console when there is one. Exception in Tkinter callback Traceback (most recent call last): File "F:\dev\3x\lib\tkinter\__init__.py", line 1885, in __call__ return self.func(*args) File "F:\dev\3x\lib\idlelib\configdialog.py", line 172, in ok self.apply() File "F:\dev\3x\lib\idlelib\configdialog.py", line 186, in apply self.activate_config_changes() File "F:\dev\3x\lib\idlelib\configdialog.py", line 240, in activate_config_changes klass.reload() File "F:\dev\3x\lib\idlelib\squeezer.py", line 222, in reload instance.load_font() File "F:\dev\3x\lib\idlelib\squeezer.py", line 318, in load_font Font(text, font=text.cget('font')).measure('0') File "F:\dev\3x\lib\idlelib\delegator.py", line 10, in __getattr__ attr = getattr(self.delegate, name) # May raise AttributeError AttributeError: 'NoneType' object has no attribute 'cget' Either the squeezer instance should be destroyed and removed along with Shell or, if keeping it is intentional, it should be removed from the update list and reinstated or if not doing that is intentional, it must either check 'if text is not None' before the access or catch the attribute error after. Tal, which? ---------- assignee: terry.reedy components: IDLE messages: 350281 nosy: taleinat, terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE: OK sometimes fails to close configdialog type: behavior versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 09:49:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 13:49:18 +0000 Subject: [issue26024] Non-ascii Windows locale names In-Reply-To: <1452090490.23.0.240691672935.issue26024@psf.upfronthosting.co.za> Message-ID: <1566568158.97.0.824039252786.issue26024@roundup.psfhosted.org> STINNER Victor added the comment: It seems like this bug has been fixed in Python 3.5, so I close the issue. What changed in Python 3.5 is that the *result* of locale.setlocale() is now the english name of the locale and so is compatible with the ASCII encoding. Vidar Fauske: > The Norwegian locale on Windows has the honor of having the only locale name with a non-ASCII character On which Windows version? On Windows 10 build 1903 with Python 3.9, it seems like locale names can be encoded/decoded from ASCII: >>> locale.setlocale(locale.LC_ALL, "swedish") 'Swedish_Sweden.1252' >>> locale.setlocale(locale.LC_ALL, "norwegian") 'Norwegian_Norway.1252' Eryk Sun confirmed that Python 3.5 doesn't seem to be affected anymore: > The issue isn't quite the same for 3.5+. The new CRT uses Windows Vista locale APIs. In this case it uses LOCALE_SENGLISHLANGUAGENAME instead of the old LOCALE_SENGLANGUAGE. This maps "Norwegian" to simply "Norwegian" instead of "Norwegian Bokm?l": --- If you consider there is still an issue with the second argument of locale.setlocale() which doesn't use the right encoding, please open a separated issue. The workaround is to use the english name of locales. For example, use 'norwegian' or 'Norwegian_Norway.1252', instead of 'Norwegian Bokm?l_Norway.1252'. ---------- resolution: third party -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 09:49:47 2019 From: report at bugs.python.org (Oguz_eren) Date: Fri, 23 Aug 2019 13:49:47 +0000 Subject: [issue37930] make fails when compiling Python 2.6 from source (posixmodule.c) Message-ID: <1566568187.35.0.524066802113.issue37930@roundup.psfhosted.org> New submission from Oguz_eren : I'm trying to compile Python 2.6.8 on Kubuntu 19.04. Current system version is Python 2.7.16. See below the error message I receive, during make. oguz at dikanka:~$ tar -xvzf Python-2.6.8.tgz oguz at dikanka:~$ cd Python-2.6.8/ oguz at dikanka:~/Python-2.6.8$ ./configure ? ? oguz at dikanka:~/Python-2.6.8$ make ? ? gcc -pthread -Xlinker -export-dynamic -o python \ Modules/python.o \ libpython2.6.a -lpthread -ldl -lutil -lm /usr/bin/ld: libpython2.6.a(posixmodule.o): in function `posix_tmpnam': /home/oguz/Python-2.6.8/./Modules/posixmodule.c:7261: warning: the use of `tmpnam_r' is dangerous, better use ` mkstemp' /usr/bin/ld: libpython2.6.a(posixmodule.o): in function `posix_tempnam': /home/oguz/Python-2.6.8/./Modules/posixmodule.c:7216: warning: the use of `tempnam' is dangerous, better use `m kstemp' Segmentation fault (core dumped) make: *** [Makefile:414: sharedmods] Error 139 I found this python bug to be very similar to my case, but it's a rather old bug : https://bugs.python.org/issue535545 Here it says, posixmodule fails because resource.h is not detected properly by configure. Similarly in my case, pyconfig.h file's HAVE_SYS_RESOURCE_H line is commented out. I also realized that my c lib headers are not under /usr/include/sys and /usr/include/bits. Instead, I can find them under the following locations : oguz at dikanka:/usr/include/linux$ find /usr/include -name resource.h /usr/include/asm-generic/resource.h /usr/include/linux/resource.h /usr/include/x86_64-linux-gnu/asm/resource.h /usr/include/x86_64-linux-gnu/bits/resource.h /usr/include/x86_64-linux-gnu/sys/resource.h I tried symlinks to x86_64-linux-gnu/sys and x86_64-linux-gnu/bits, but the the issue persists. Any ideas ? Thanks in advance! ---------- components: Installation messages: 350283 nosy: Oguz_eren priority: normal severity: normal status: open title: make fails when compiling Python 2.6 from source (posixmodule.c) type: compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 09:51:32 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 13:51:32 +0000 Subject: [issue34521] Multiple tests (test_socket, test_multiprocessing_*) fail due to incorrect recvmsg(2) buffer lengths, causing failures on FreeBSD CURRENT In-Reply-To: <1535389978.32.0.56676864532.issue34521@psf.upfronthosting.co.za> Message-ID: <1566568292.67.0.879616511152.issue34521@roundup.psfhosted.org> STINNER Victor added the comment: "AMD64 FreeBSD CURRENT Shared 2.7 #159 is complete: Success" https://buildbot.python.org/all/#/builders/169/builds/159 The FreeBSD 2.7 buildbot is back to green, I close the issue. Thanks everyone was helped to get these issues to be fixed! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 09:52:05 2019 From: report at bugs.python.org (Oguz_eren) Date: Fri, 23 Aug 2019 13:52:05 +0000 Subject: [issue37930] make fails when compiling Python 2.6 from source (posixmodule.c) In-Reply-To: <1566568187.35.0.524066802113.issue37930@roundup.psfhosted.org> Message-ID: <1566568325.98.0.612637034222.issue37930@roundup.psfhosted.org> Change by Oguz_eren : Added file: https://bugs.python.org/file48558/config.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 09:54:35 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Fri, 23 Aug 2019 13:54:35 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1566568475.91.0.106571160861.issue29535@roundup.psfhosted.org> Ashwin Ramaswami added the comment: Makes sense, thanks for the explanation. The risk is that if there is code that, say, converts a POST dictionary to a dictionary with numeric keys, that code could be exploited. Creating a non-deterministic hash doesn't necessarily preclude hash(x) = x for a small enough x either. Given that other libraries (NumPy, etc.) rely on the numeric hash staying the way it is, it makes sense to keep it as it is. Since when did something that seems at first glance to be an implementation detail become more like a backwards-incompatible API, though? (For example, the implementation of the numeric hash was changed without any backwards-compatibility issues in https://bugs.python.org/issue14621). Might there be a better way to clarify this distinction for other features in Python? I think the way forward for this patch is to keep the datetime hash as it is, and remove "datetime" in the parts of documentation that enumerate which data types have non-deterministic hashes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:02:52 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 23 Aug 2019 14:02:52 +0000 Subject: [issue37428] SSLContext.post_handshake_auth implicitly enables cert validation In-Reply-To: <1561631609.42.0.922673247425.issue37428@roundup.psfhosted.org> Message-ID: <1566568972.94.0.0352759664051.issue37428@roundup.psfhosted.org> ?ukasz Langa added the comment: Should this be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:03:06 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 23 Aug 2019 14:03:06 +0000 Subject: [issue37440] httplib should enable post-handshake authentication for TLS 1.3 In-Reply-To: <1561732145.9.0.0353203933987.issue37440@roundup.psfhosted.org> Message-ID: <1566568986.89.0.107173697727.issue37440@roundup.psfhosted.org> ?ukasz Langa added the comment: Should this be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:03:56 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 23 Aug 2019 14:03:56 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566569036.13.0.220188965671.issue34679@roundup.psfhosted.org> ?ukasz Langa added the comment: Please fix this ASAP, last 3.8 beta is scheduled for Monday. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:04:41 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 23 Aug 2019 14:04:41 +0000 Subject: [issue37830] continue and break in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1566569081.25.0.646031217176.issue37830@roundup.psfhosted.org> ?ukasz Langa added the comment: This is marked as a release blocker. The last beta is scheduled for Monday. Please decide how to proceed ASAP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:05:25 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 23 Aug 2019 14:05:25 +0000 Subject: [issue37549] os.dup() fails for standard streams on Windows 7 In-Reply-To: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org> Message-ID: <1566569125.34.0.904944309375.issue37549@roundup.psfhosted.org> ?ukasz Langa added the comment: This is marked as a release blocker. The last beta is scheduled for Monday. Please decide how to proceed ASAP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:07:28 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 23 Aug 2019 14:07:28 +0000 Subject: [issue34155] email.utils.parseaddr mistakenly parse an email In-Reply-To: <1532012023.85.0.56676864532.issue34155@psf.upfronthosting.co.za> Message-ID: <1566569248.6.0.63202680373.issue34155@roundup.psfhosted.org> ?ukasz Langa added the comment: Downgraded the severity since 3.6 - 3.9 are merged. ---------- nosy: +lukasz.langa priority: deferred blocker -> critical _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:08:52 2019 From: report at bugs.python.org (Bruno Oliveira) Date: Fri, 23 Aug 2019 14:08:52 +0000 Subject: [issue37549] os.dup() fails for standard streams on Windows 7 In-Reply-To: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org> Message-ID: <1566569332.28.0.115676807398.issue37549@roundup.psfhosted.org> Change by Bruno Oliveira : ---------- nosy: +Bruno Oliveira _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:09:32 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 23 Aug 2019 14:09:32 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1566569372.7.0.0653526540586.issue37757@roundup.psfhosted.org> ?ukasz Langa added the comment: This is marked as a release blocker. The last beta is scheduled for Monday. Please decide how to proceed ASAP. ---------- nosy: +lukasz.langa priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:09:52 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 23 Aug 2019 14:09:52 +0000 Subject: [issue37055] Numerous warnings with blake2 module In-Reply-To: <1558886932.4.0.665756848832.issue37055@roundup.psfhosted.org> Message-ID: <1566569392.29.0.572421775064.issue37055@roundup.psfhosted.org> ?ukasz Langa added the comment: This is marked as a release blocker. The last beta is scheduled for Monday. Please decide how to proceed ASAP. ---------- nosy: +lukasz.langa priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:10:27 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 23 Aug 2019 14:10:27 +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: <1566569427.17.0.182499520728.issue35998@roundup.psfhosted.org> ?ukasz Langa added the comment: Should this be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:11:53 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 23 Aug 2019 14:11:53 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566569513.32.0.594712820957.issue36205@roundup.psfhosted.org> ?ukasz Langa added the comment: This is marked as a release blocker. The last beta is scheduled for Monday. Please decide how to proceed ASAP. ---------- priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:12:38 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 23 Aug 2019 14:12:38 +0000 Subject: [issue36344] install_certificates.command too complicated In-Reply-To: <1552911860.35.0.715970160231.issue36344@roundup.psfhosted.org> Message-ID: <1566569558.18.0.768436427207.issue36344@roundup.psfhosted.org> ?ukasz Langa added the comment: This is marked as a release blocker. The last 3.8 beta is scheduled for Monday. Please decide how to proceed ASAP. ---------- nosy: +benjamin.peterson, lukasz.langa priority: deferred blocker -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:18:36 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Fri, 23 Aug 2019 14:18:36 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1566569916.1.0.469012070331.issue29535@roundup.psfhosted.org> Ashwin Ramaswami added the comment: Oh, that PR is already there in PR 15269, great! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:32:29 2019 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 23 Aug 2019 14:32:29 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566570749.79.0.186378282234.issue34679@roundup.psfhosted.org> Yury Selivanov added the comment: Andrew, can you fix ctrl-c/windows issue? I'm basically afk until monday. And we're not going to do anything about add_signal_handler in 3.8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:33:38 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 23 Aug 2019 14:33:38 +0000 Subject: [issue37055] Numerous warnings with blake2 module In-Reply-To: <1558886932.4.0.665756848832.issue37055@roundup.psfhosted.org> Message-ID: <1566570818.81.0.432320813.issue37055@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Related to this, the blake2 function (declared as static inline) is not used, which makes the Solaris and compilers unhappy. Patch for reference: --- a/Modules/_blake2/impl/blake2.h +++ b/Modules/_blake2/impl/blake2.h @@ -169,11 +169,6 @@ BLAKE2_API int blake2sp( uint8_t *out, const void *in, const void *key, size_t outlen, size_t inlen, size_t keylen ); BLAKE2_API int blake2bp( uint8_t *out, const void *in, const void *key, size_t outlen, size_t inlen, size_t keylen ); - static inline int blake2( uint8_t *out, const void *in, const void *key, size_t outlen, size_t inlen, size_t keylen ) - { - return blake2b( out, in, key, outlen, inlen, keylen ); - } - #if defined(__cplusplus) } #endif ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:41:03 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 23 Aug 2019 14:41:03 +0000 Subject: [issue37830] continue and break in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1566571263.63.0.0733449052994.issue37830@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: I think PR 15320 should be merge as soon as possible at least to fix the segfault and stop the release blocker. Anything else can wait IMHO ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:44:37 2019 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 23 Aug 2019 14:44:37 +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: <1566571477.86.0.232731166711.issue14465@roundup.psfhosted.org> Stefan Behnel added the comment: New changeset b5d3ceea48c181b3e2c6c67424317afed606bd39 by Stefan Behnel in branch 'master': bpo-14465: Add an indent() function to xml.etree.ElementTree to pretty-print XML trees (GH-15200) https://github.com/python/cpython/commit/b5d3ceea48c181b3e2c6c67424317afed606bd39 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:45:28 2019 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 23 Aug 2019 14:45:28 +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: <1566571528.92.0.74647805054.issue14465@roundup.psfhosted.org> Change by Stefan Behnel : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 10:54:26 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Fri, 23 Aug 2019 14:54:26 +0000 Subject: [issue37930] make fails when compiling Python 2.6 from source (posixmodule.c) In-Reply-To: <1566568187.35.0.524066802113.issue37930@roundup.psfhosted.org> Message-ID: <1566572066.81.0.0575413155564.issue37930@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Hi Oguz, Sadly Python 2.6.8 is not supported anymore ---------- nosy: +pablogsal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:03:50 2019 From: report at bugs.python.org (Vidar Fauske) Date: Fri, 23 Aug 2019 15:03:50 +0000 Subject: [issue10466] locale.py resetlocale throws exception on Windows (getdefaultlocale returns value not usable in setlocale) In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za> Message-ID: <1566572630.85.0.529671113013.issue10466@roundup.psfhosted.org> Vidar Fauske added the comment: Note that this is still an issue on Windows: >>> import locale >>> locale.getdefaultlocale() ('en_US', 'cp1252') >>> locale.setlocale(locale.getdefaultlocale()) Error: unsupported locale setting ---------- components: +Windows nosy: +paul.moore, steve.dower, vidartf, zach.ware versions: +Python 3.7 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:05:54 2019 From: report at bugs.python.org (Brett Slatkin) Date: Fri, 23 Aug 2019 15:05:54 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566572754.87.0.78026798972.issue34679@roundup.psfhosted.org> Brett Slatkin added the comment: Maybe we should just roll back https://bugs.python.org/issue34687 to fix both issues? Otherwise asyncio will be broken on Windows in 3.8. Is general API stability more important than performance? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:08:15 2019 From: report at bugs.python.org (Tim Peters) Date: Fri, 23 Aug 2019 15:08:15 +0000 Subject: [issue37454] Clarify docs for math.log1p() In-Reply-To: <1561933178.32.0.315765765879.issue37454@roundup.psfhosted.org> Message-ID: <1566572895.77.0.918786510339.issue37454@roundup.psfhosted.org> Tim Peters added the comment: > Sometimes you guys make me feel dumb as a rock. I expect we all do that favor for each other at times ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:09:23 2019 From: report at bugs.python.org (Vidar Fauske) Date: Fri, 23 Aug 2019 15:09:23 +0000 Subject: [issue26024] Non-ascii Windows locale names In-Reply-To: <1452090490.23.0.240691672935.issue26024@psf.upfronthosting.co.za> Message-ID: <1566572963.44.0.475328506092.issue26024@roundup.psfhosted.org> Vidar Fauske added the comment: Thanks. Note that the failing with ` locale.setlocale(locale.LC_ALL, locale.getdefaultlocale())` I mentioned above is a different problem, that is tracked in a much older issue: https://bugs.python.org/issue10466 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:19:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 15:19:25 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566573565.01.0.0335325337265.issue36763@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15122 pull_request: https://github.com/python/cpython/pull/15423 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:19:25 2019 From: report at bugs.python.org (Daniel Himmelstein) Date: Fri, 23 Aug 2019 15:19:25 +0000 Subject: [issue34898] add mtime argument to gzip.compress In-Reply-To: <1538688124.68.0.545547206417.issue34898@psf.upfronthosting.co.za> Message-ID: <1566573565.41.0.0637791729325.issue34898@roundup.psfhosted.org> Daniel Himmelstein added the comment: Any reason not to also expose mtime in the gzip.open API? ---------- nosy: +dhimmel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:29:03 2019 From: report at bugs.python.org (Zackery Spytz) Date: Fri, 23 Aug 2019 15:29:03 +0000 Subject: [issue23878] Missing sanity checks for various C library function calls... In-Reply-To: <1428339627.31.0.628073381935.issue23878@psf.upfronthosting.co.za> Message-ID: <1566574143.57.0.911293904744.issue23878@roundup.psfhosted.org> Change by Zackery Spytz : ---------- pull_requests: +15123 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15424 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:30:08 2019 From: report at bugs.python.org (Zackery Spytz) Date: Fri, 23 Aug 2019 15:30:08 +0000 Subject: [issue23878] Missing sanity checks for various C library function calls... In-Reply-To: <1428339627.31.0.628073381935.issue23878@psf.upfronthosting.co.za> Message-ID: <1566574208.05.0.554403578068.issue23878@roundup.psfhosted.org> Change by Zackery Spytz : ---------- nosy: +ZackerySpytz versions: +Python 2.7, Python 3.7, Python 3.8, Python 3.9 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:38:46 2019 From: report at bugs.python.org (Neha Reddy) Date: Fri, 23 Aug 2019 15:38:46 +0000 Subject: [issue31727] FTP_TLS errors when use certain subcommands In-Reply-To: <1507482521.5.0.213398074469.issue31727@psf.upfronthosting.co.za> Message-ID: <1566574726.74.0.62409983594.issue31727@roundup.psfhosted.org> Neha Reddy added the comment: We faced the same issue while trying to copy files to an FTPS server. We are trying to connect to a Filezilla server. The type of encryption we are using for the FTPS is 'Require explicit FTP over TLS'. There are the errors that my colleague and I had while trying to use the ftp.nlst() or the storbinary() functions in ftplib. EOF occurred in violation of protocol (_ssl.c:852) OSError: [Errno 0] Error After some research on the internet, we found a workaround on stack overflow (https://stackoverflow.com/questions/46633536/getting-a-oserror-when-trying-to-list-ftp-directories-in-python) Below is the code for the workaround. hoping this could help resolve the issue in the newer version. import ftplib from ssl import SSLSocket class ReusedSslSocket(SSLSocket): def unwrap(self): pass class MyFTP_TLS(ftplib.FTP_TLS): """Explicit FTPS, with shared TLS session""" def ntransfercmd(self, cmd, rest=None): conn, size = ftplib.FTP.ntransfercmd(self, cmd, rest) if self._prot_p: conn = self.context.wrap_socket(conn, server_hostname=self.host, session=self.sock.session) # reuses TLS session conn.__class__ = ReusedSslSocket # we should not close reused ssl socket when file transfers finish return conn, size ---------- nosy: +realnehareddy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:39:47 2019 From: report at bugs.python.org (Benoit Hudson) Date: Fri, 23 Aug 2019 15:39:47 +0000 Subject: [issue37931] crash reimporting posix after Py_Finalize on mac Message-ID: <1566574787.75.0.458129578699.issue37931@roundup.psfhosted.org> New submission from Benoit Hudson : On OSX, with --enable-shared, if you shut down python and reinitialize, you can get a crash. Repro steps: see attached crashy.c gcc -I. -I ../Include/ -L. crashy.c -lpython3.9 ./a.out On OSX, with --enable-shared, you get a crash! On other platforms including on OSX static builds, no crash. Not a regression: it's present in 2.7 (where we actually hit it). PR incoming, the fix is simple. It has to do with caching (on OSX shared builds only) a stale value for the environment when building os.environ the first time; if you change the environment, the second initialization reads garbage when building os.environ. ---------- components: Interpreter Core, macOS files: crashy.c messages: 350309 nosy: Benoit Hudson, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: crash reimporting posix after Py_Finalize on mac type: crash versions: Python 3.9 Added file: https://bugs.python.org/file48559/crashy.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:48:46 2019 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 23 Aug 2019 15:48:46 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1566575326.36.0.225968663108.issue37757@roundup.psfhosted.org> Guido van Rossum added the comment: The decision has been made to get rid of TargetScopeError and instead just use SyntaxError. PEP 572 was updated already. We're just waiting for someone (Serhiy?) to review Nick's patch, PR #15131. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:57:57 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 15:57:57 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566575877.73.0.913430341113.issue36763@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 3842f2997fbd4dc840986aad2bb94656815e243b by Victor Stinner in branch 'master': bpo-36763: Implement PyWideStringList_Insert() of PEP 587 (GH-15423) https://github.com/python/cpython/commit/3842f2997fbd4dc840986aad2bb94656815e243b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 11:58:07 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 15:58:07 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566575887.38.0.963109136865.issue36763@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15124 pull_request: https://github.com/python/cpython/pull/15427 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 12:07:35 2019 From: report at bugs.python.org (Benoit Hudson) Date: Fri, 23 Aug 2019 16:07:35 +0000 Subject: [issue37931] crash reimporting posix after Py_Finalize on mac In-Reply-To: <1566574787.75.0.458129578699.issue37931@roundup.psfhosted.org> Message-ID: <1566576455.5.0.848959535519.issue37931@roundup.psfhosted.org> Change by Benoit Hudson : ---------- keywords: +patch pull_requests: +15125 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15428 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 12:24:45 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 16:24:45 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566577485.25.0.216016193254.issue36763@roundup.psfhosted.org> miss-islington added the comment: New changeset a6427cb2a279c4125dc26d468bcbb3374cdc5f41 by Miss Islington (bot) in branch '3.8': bpo-36763: Implement PyWideStringList_Insert() of PEP 587 (GH-15423) https://github.com/python/cpython/commit/a6427cb2a279c4125dc26d468bcbb3374cdc5f41 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 12:46:09 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 16:46:09 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566578769.13.0.6451189478.issue36763@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15126 pull_request: https://github.com/python/cpython/pull/15431 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 12:48:49 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 16:48:49 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566578929.2.0.181422754707.issue36763@roundup.psfhosted.org> STINNER Victor added the comment: > _PySys_ReadPreInitOptions() code should be moved somewhere closer to PyConfig_Read(). Done in PR 15431. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 12:51:55 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 16:51:55 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566579115.79.0.9671276452.issue36763@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15127 pull_request: https://github.com/python/cpython/pull/15433 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 12:52:18 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 16:52:18 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566579138.8.0.337087997296.issue36763@roundup.psfhosted.org> STINNER Victor added the comment: > The first doc should mention somewhere the new doc. Done in PR 15433. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 12:59:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 16:59:15 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566579555.31.0.583668345201.issue36763@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 1beb7c3de9c3d0e802e4267a11d937e8f024d661 by Victor Stinner in branch 'master': bpo-36763, doc: Add links in the new C API init doc (GH-15433) https://github.com/python/cpython/commit/1beb7c3de9c3d0e802e4267a11d937e8f024d661 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 12:59:27 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 16:59:27 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566579567.32.0.558380406319.issue36763@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15128 pull_request: https://github.com/python/cpython/pull/15434 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 13:03:11 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 17:03:11 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566579791.09.0.226156634999.issue36763@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 120b707a6d43452e067daa55a8fdca69f9424abc by Victor Stinner in branch 'master': bpo-36763: PyConfig_Read() handles PySys_AddXOption() (GH-15431) https://github.com/python/cpython/commit/120b707a6d43452e067daa55a8fdca69f9424abc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 13:06:02 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 17:06:02 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566579962.29.0.149469483904.issue36763@roundup.psfhosted.org> miss-islington added the comment: New changeset 9cbdce3917ab41856b61ac5c0f3c4ac0e203f320 by Miss Islington (bot) in branch '3.8': bpo-36763, doc: Add links in the new C API init doc (GH-15433) https://github.com/python/cpython/commit/9cbdce3917ab41856b61ac5c0f3c4ac0e203f320 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 13:06:42 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 17:06:42 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566580002.37.0.623144051951.issue36763@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15129 pull_request: https://github.com/python/cpython/pull/15435 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 13:19:19 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 17:19:19 +0000 Subject: [issue26589] Add HTTP Response code 451 In-Reply-To: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za> Message-ID: <1566580759.45.0.330760677185.issue26589@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 8f080b09953a2d862de5c74edf414a54ea3dbea5 by Raymond Hettinger in branch 'master': bpo-26589: Add http status code 451 (GH-15413) https://github.com/python/cpython/commit/8f080b09953a2d862de5c74edf414a54ea3dbea5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 13:20:51 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 17:20:51 +0000 Subject: [issue26589] Add HTTP Response code 451 In-Reply-To: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za> Message-ID: <1566580851.69.0.684011003896.issue26589@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15130 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/15436 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 13:55:34 2019 From: report at bugs.python.org (hai shi) Date: Fri, 23 Aug 2019 17:55:34 +0000 Subject: [issue9938] Add optional kwargs to argparse In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za> Message-ID: <1566582934.86.0.614295477604.issue9938@roundup.psfhosted.org> Change by hai shi : ---------- title: Improving interactive use of argparse -> Add optional kwargs to argparse _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 13:56:49 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 17:56:49 +0000 Subject: [issue26589] Add HTTP Response code 451 In-Reply-To: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za> Message-ID: <1566583009.17.0.341018099108.issue26589@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 761e5a7c7f57cf2a09106c0afa038f04de6a9ed2 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-26589: Add http status code 451 (GH-15413) (GH-15436) https://github.com/python/cpython/commit/761e5a7c7f57cf2a09106c0afa038f04de6a9ed2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 13:57:01 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 17:57:01 +0000 Subject: [issue26589] Add HTTP Response code 451 In-Reply-To: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za> Message-ID: <1566583021.8.0.5913075751.issue26589@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 14:00:16 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 23 Aug 2019 18:00:16 +0000 Subject: [issue17642] IDLE add font resizing hot keys and wheel In-Reply-To: <1365228385.87.0.236246362772.issue17642@psf.upfronthosting.co.za> Message-ID: <1566583216.44.0.620147124736.issue17642@roundup.psfhosted.org> Terry J. Reedy added the comment: I want this too, and part of it should be simple. Given that I have had a never empty backlog of PRs to review for 2 1/2 years, it got forgotten. There was also a tk problem that seemed to block implementation. Specification for hotkey: Cntl/Cmd - -+= decrease/increase font size within limits in the current window only. (The current limits for turtledemo are 6 and 100. Change this? The keys are fixed and cannot be customized. Keys have no affect on IdleConf. Setting font size in dialog continues to set font size for all Windows, whether individually set or not. Should work same for editor and text (read-only) windows. As near as I can tell, these key combinations currently do nothing. I presume they are not bound in the built-in keysets. Custom keysets are always subject to interference when we add new key bindings. (I don't know that the custom key dialog checks against such fixed builtins. Another issue. Checking custom keysets on import is likely a third issue.) Implementation for hotkey: The desired behavior is the behavior of turtledemo, so the same implementation should work. It is annoying that we need to add it separately for editor and text windows. But refactoring to create a common base class would be a lot harder. Mousewheel: Currently, in turtledemo, control-wheel changes size on all systems. Raymond: Should it be cmd-wheel on Mac? In msg226328 I reported a tk issue blocking both this and line numbers. We now deliver 3.7.4 and 3.8.0 with tk 8.6.9. We have line numbers because I no longer saw the glitchy behavior I remember. Nor did I see any issue with font resizing with turtledemo. I may include the module browser, etc, with this issue. Dialogs would be another issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 14:01:44 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 23 Aug 2019 18:01:44 +0000 Subject: [issue14112] tutorial intro talks of "shallow copy" concept without explanation In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za> Message-ID: <1566583304.41.0.0751347685525.issue14112@roundup.psfhosted.org> Terry J. Reedy added the comment: With /like/link/ I agree. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 14:02:23 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 23 Aug 2019 18:02:23 +0000 Subject: [issue37549] os.dup() fails for standard streams on Windows 7 In-Reply-To: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org> Message-ID: <1566583343.29.0.463561472061.issue37549@roundup.psfhosted.org> Eryk Sun added the comment: > Should we add a version check as well [1]? I'm not totally comfortable > with bitmasking a handle here, but if we only do this additional > check on Win7 then I'm okay with it. A version check should not be necessary. For file objects, setting both handle tag bits has always been a reserved signature for console pseudohandles. Here's the definition in the published console code: https://github.com/microsoft/terminal/blob/b726a3d05d35928becc8313f6ac5536c9f503645/dep/Console/winconp.h#L460 It's mostly vestigial in Windows 8+ due to the addition of the ConDrv console device. Code that routed calls to LPC-based implementations when passed a console pseudohandle has all been removed. The only remaining use I know of is in the console attach code. If a process is started with STARTF_USESTDHANDLES, then AllocConsole() will only replace handles that are NULL or console pseudohandles. The docs for GetStdHandle explain this: Attach/detach behavior When attaching to a new console, standard handles are always replaced with console handles unless STARTF_USESTDHANDLES was specified during process creation. If the existing value of the standard handle is NULL, or the existing value of the standard handle looks like a console pseudohandle, the handle is replaced with a console handle. When a parent uses both CREATE_NEW_CONSOLE and STARTF_USESTDHANDLES to create a console process, standard handles will not be replaced unless the existing value of the standard handle is NULL or a console pseudohandle. I confirmed that this is still relevant in Windows 10 by testing an inherited pipe handle in stdout and stderr and manually setting the tag bits in the hStdError handle value in STARTUPINFO. The console attach code preserved the regular handle in stdout but replaced the console pseudohandle in stderr. So the API is still reserving these tag bits in file handles, at least in one place, which means they're still reserved in general, even though setting them will no longer break a ReadFile call, for one example, like it would in Windows 7 (in which the API would route the call to the internal ReadConsole implementation). We've been relying on checking the console pseudohandle tag bits without a version check in subprocess.Popen._filter_handle_list for a while now. Console pseudohandles have to be removed from the handle list, else CreateProcessW will fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 14:37:59 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 23 Aug 2019 18:37:59 +0000 Subject: [issue37549] os.dup() fails for standard streams on Windows 7 In-Reply-To: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org> Message-ID: <1566585479.82.0.278222281736.issue37549@roundup.psfhosted.org> Steve Dower added the comment: Thanks, Eryk. In that case, I'll merge the PR. Since Python 3.9 will not support Windows 7, we can remove it from master as soon as the backports are done :) ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 14:38:44 2019 From: report at bugs.python.org (Steve Dower) Date: Fri, 23 Aug 2019 18:38:44 +0000 Subject: [issue37549] os.dup() fails for standard streams on Windows 7 In-Reply-To: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org> Message-ID: <1566585524.28.0.890248422671.issue37549@roundup.psfhosted.org> Steve Dower added the comment: New changeset 5be666010e4df65dc4d831435cc92340ea369f94 by Steve Dower (Zackery Spytz) in branch 'master': bpo-37549: os.dup() fails for standard streams on Windows 7 (GH-15389) https://github.com/python/cpython/commit/5be666010e4df65dc4d831435cc92340ea369f94 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 14:38:56 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 18:38:56 +0000 Subject: [issue37549] os.dup() fails for standard streams on Windows 7 In-Reply-To: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org> Message-ID: <1566585536.68.0.472621355395.issue37549@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15131 pull_request: https://github.com/python/cpython/pull/15437 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 14:39:03 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 18:39:03 +0000 Subject: [issue37549] os.dup() fails for standard streams on Windows 7 In-Reply-To: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org> Message-ID: <1566585543.34.0.0325715790325.issue37549@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15132 pull_request: https://github.com/python/cpython/pull/15438 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 14:48:18 2019 From: report at bugs.python.org (Ned Deily) Date: Fri, 23 Aug 2019 18:48:18 +0000 Subject: [issue37916] distutils: allow overriding of the RANLIB command on macOS (darwin) In-Reply-To: <1566473837.96.0.294748627211.issue37916@roundup.psfhosted.org> Message-ID: <1566586098.28.0.699821959445.issue37916@roundup.psfhosted.org> Change by Ned Deily : ---------- components: +Distutils nosy: +dstufft, eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 14:59:13 2019 From: report at bugs.python.org (Ned Deily) Date: Fri, 23 Aug 2019 18:59:13 +0000 Subject: [issue37930] make fails when compiling Python 2.6 from source (posixmodule.c) In-Reply-To: <1566568187.35.0.524066802113.issue37930@roundup.psfhosted.org> Message-ID: <1566586753.95.0.363771924716.issue37930@roundup.psfhosted.org> Ned Deily added the comment: Python 2.6 reached end-of-life in 2013, six years ago, and has not received any non-security bug fixes since 2010. We strongly recommend thst you migrate to a modern, supported version of Python, if not Python 3.7, then at least Python 2.7 which itself will reach end-of-life in 2020. ---------- nosy: +ned.deily resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 15:01:43 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 19:01:43 +0000 Subject: [issue37549] os.dup() fails for standard streams on Windows 7 In-Reply-To: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org> Message-ID: <1566586903.84.0.392970686786.issue37549@roundup.psfhosted.org> miss-islington added the comment: New changeset f8dc3e85ab01e1b0345738670dcb3993da7ec436 by Miss Islington (bot) in branch '3.7': bpo-37549: os.dup() fails for standard streams on Windows 7 (GH-15389) https://github.com/python/cpython/commit/f8dc3e85ab01e1b0345738670dcb3993da7ec436 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 15:04:30 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 19:04:30 +0000 Subject: [issue37549] os.dup() fails for standard streams on Windows 7 In-Reply-To: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org> Message-ID: <1566587070.65.0.681818447239.issue37549@roundup.psfhosted.org> miss-islington added the comment: New changeset 3921d12174c1998d9df7a08d036a7fef2d587a64 by Miss Islington (bot) in branch '3.8': bpo-37549: os.dup() fails for standard streams on Windows 7 (GH-15389) https://github.com/python/cpython/commit/3921d12174c1998d9df7a08d036a7fef2d587a64 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 15:16:55 2019 From: report at bugs.python.org (STINNER Victor) Date: Fri, 23 Aug 2019 19:16:55 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566587815.32.0.439937299303.issue36763@roundup.psfhosted.org> STINNER Victor added the comment: New changeset af84a88ef8b3288da528d2f52b7d3fbafb8dc8a6 by Victor Stinner in branch '3.8': bpo-36763: PyConfig_Read() handles PySys_AddXOption() (GH-15431) (GH-15435) https://github.com/python/cpython/commit/af84a88ef8b3288da528d2f52b7d3fbafb8dc8a6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 15:19:06 2019 From: report at bugs.python.org (Eryk Sun) Date: Fri, 23 Aug 2019 19:19:06 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566587946.83.0.0416086330908.issue37531@roundup.psfhosted.org> Eryk Sun added the comment: Alternatively, instead of special casing the file type and spinning on PeekNamedPipe, the workaround could be based on a multiple-object wait that includes the child process handle. In this case, communicate() would always call _communicate in Windows, regardless of the timeout or number of pipes -- because simplistically calling either self.stdout.read() or self.stderr.read() could hang. The implementation would be moderately complicated. If we stop waiting on the reader threads because the process exited, we can give the threads a short time to finish reading and close the files -- maybe 250 ms is enough. But if they haven't exited at this time, we can't simply raise a TimeoutExpired exception if the call hasn't actually timed out. To finish the _communicate call, we would have to cancel the pending reads and join() the threads. We can force a reader thread to exit by canceling the read via WINAPI CancelIoEx. However, _readerthread has to be modified to support this. It could be implemented as a loop that calls _winapi.ReadFile to read the output in chunks that get appended to the buffer list. The read loop would break for either ERROR_BROKEN_PIPE or ERROR_OPERATION_ABORTED (canceled). The final step in _communicate would be to concatenate the partial reads. If it's text mode, it would also have to decode the bytes and translate newlines. The POSIX implementation of _communicate has to do this, so we already have a _translate_newlines method for this case. Note that _winapi.WaitForMultipleObjects is interruptible in the main thread via Ctrl+C, which is a bonus improvement since Thread.join() can't be interrupted in Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 15:53:59 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Fri, 23 Aug 2019 19:53:59 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566590039.02.0.471164394746.issue37884@roundup.psfhosted.org> Jeroen Demeyer added the comment: > FWIW, the entire point of us having recently added as_integer_ratio() methods to so many concrete classes is to avoid the need for helper functions in favor of a simple try/except around a single call. But what about PEP 3141? The fractions.Fraction constructor accepts numbers.Rational instances, which do not necessarily have an as_integer_ratio() method. We can't just drop support for that (*). So in practice you do need to check both as_integer_ratio() and the PEP 3141 numerator/denominator properties. It seems useful to have a helper function for this. (*) Unless you want to deprecate PEP 3141. This may be less crazy than it sounds, especially given Guido van Rossum's reaction on https://discuss.python.org/t/pep-3141-ratio-instead-of-numerator-denominator/2037/25?u=jdemeyer ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 16:58:17 2019 From: report at bugs.python.org (Sean Robertson) Date: Fri, 23 Aug 2019 20:58:17 +0000 Subject: [issue37932] ConfigParser.items(section) with allow_no_value returns empty strings Message-ID: <1566593897.26.0.561388114417.issue37932@roundup.psfhosted.org> New submission from Sean Robertson : Hello and thanks for reading. I've also experienced this in Python 3.7, and I believe it to be around since 3.2. The allow_no_value option of ConfigParser allows None values when (de)serializing configuration files. Yet calling the "items(section)" method of a ConfigParser returns empty strings for values instead of None. See below for an MRE. Thanks, Sean Python 3.6.8 (default, Jan 14 2019, 11:02:34) [GCC 8.0.1 20180414 (experimental) [trunk revision 259383]] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from configparser import ConfigParser >>> a = ConfigParser(allow_no_value=True) >>> a.add_section('foo') >>> a.set('foo', 'bar') >>> a.items('foo') [('bar', '')] >>> a.items('foo', raw=True) [('bar', None)] >>> a.get('foo', 'bar') >>> list(a['foo'].items()) [('bar', None)] ---------- components: Library (Lib) messages: 350331 nosy: Sean Robertson priority: normal severity: normal status: open title: ConfigParser.items(section) with allow_no_value returns empty strings type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 17:23:01 2019 From: report at bugs.python.org (Thomas Caswell) Date: Fri, 23 Aug 2019 21:23:01 +0000 Subject: [issue37933] faulthandler causes segfaults Message-ID: <1566595381.91.0.0185169812386.issue37933@roundup.psfhosted.org> New submission from Thomas Caswell : Changing faulthandler to only allocate it's stack when use causes python to segfault with import faulthandler faulthandler.cancel_dump_traceback_later() https://bugs.python.org/issue37851 https://github.com/python/cpython/pull/15358 ---------- components: Library (Lib) messages: 350332 nosy: tcaswell, vstinner priority: normal severity: normal status: open title: faulthandler causes segfaults type: crash versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 17:24:40 2019 From: report at bugs.python.org (Thomas Caswell) Date: Fri, 23 Aug 2019 21:24:40 +0000 Subject: [issue37933] faulthandler causes segfaults In-Reply-To: <1566595381.91.0.0185169812386.issue37933@roundup.psfhosted.org> Message-ID: <1566595480.8.0.185980984172.issue37933@roundup.psfhosted.org> Change by Thomas Caswell : ---------- components: +Extension Modules -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 17:35:38 2019 From: report at bugs.python.org (Kyle Stanley) Date: Fri, 23 Aug 2019 21:35:38 +0000 Subject: [issue37585] Comparing PyDictValues does not give expected results In-Reply-To: <1563019128.62.0.639495498673.issue37585@roundup.psfhosted.org> Message-ID: <1566596138.57.0.742129996591.issue37585@roundup.psfhosted.org> Change by Kyle Stanley : ---------- stage: resolved -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 17:49:06 2019 From: report at bugs.python.org (Kyle Stanley) Date: Fri, 23 Aug 2019 21:49:06 +0000 Subject: [issue37934] Docs: Clarify NotImplemented use cases Message-ID: <1566596946.3.0.57144717386.issue37934@roundup.psfhosted.org> New submission from Kyle Stanley : In the documentation for the NotImplemented constant (https://docs.python.org/3/library/constants.html#NotImplemented), the only use case mentioned is for binary special methods, (such as object.__eq__(other)). However, based on a conversation in a recent PR (https://github.com/python/cpython/pull/15327#discussion_r316561140), there seems be several other use cases as well. It's quite useful to utilize when it's desired to express that a particular operation is not supported, without raising an error. Expanding upon the use cases will provide readers an idea of other cases in which the constant could be useful. Also, the current wording could potentially come across as implying that the _only_ use case for the constant is for binary special methods, and as far as I'm aware, that is not the case. ---------- assignee: docs at python components: Documentation keywords: easy messages: 350333 nosy: aeros167, docs at python, eric.araujo, ezio.melotti, mdk, willingc priority: normal severity: normal stage: needs patch status: open title: Docs: Clarify NotImplemented use cases type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 17:54:17 2019 From: report at bugs.python.org (Thomas Caswell) Date: Fri, 23 Aug 2019 21:54:17 +0000 Subject: [issue37933] faulthandler causes segfaults In-Reply-To: <1566595381.91.0.0185169812386.issue37933@roundup.psfhosted.org> Message-ID: <1566597257.21.0.0440720059308.issue37933@roundup.psfhosted.org> Change by Thomas Caswell : ---------- keywords: +patch pull_requests: +15133 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15440 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 17:58:33 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 21:58:33 +0000 Subject: [issue22001] containers "same" does not always mean "__eq__". In-Reply-To: <1405625961.78.0.30088981548.issue22001@psf.upfronthosting.co.za> Message-ID: <1566597513.79.0.250056677321.issue22001@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 18:01:14 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 22:01:14 +0000 Subject: [issue29352] provide the authorative source for s[i:j] negative slice indices (<-len(s)) behavior for standard sequences In-Reply-To: <1485190156.24.0.631194950251.issue29352@psf.upfronthosting.co.za> Message-ID: <1566597674.05.0.826665897432.issue29352@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 18:11:35 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 22:11:35 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> Message-ID: <1566598295.6.0.117018837912.issue18078@roundup.psfhosted.org> Raymond Hettinger added the comment: Marking this as closed/rejected for the reasons listed above. Thank you all for the thoughtful and intelligent discussion. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 18:20:35 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 22:20:35 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566598835.2.0.893991316416.issue37798@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 0a18ee4be7ba215f414bef04598e0849504f9f1e by Raymond Hettinger (Dong-hee Na) in branch 'master': bpo-37798: Add C fastpath for statistics.NormalDist.inv_cdf() (GH-15266) https://github.com/python/cpython/commit/0a18ee4be7ba215f414bef04598e0849504f9f1e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 18:20:45 2019 From: report at bugs.python.org (miss-islington) Date: Fri, 23 Aug 2019 22:20:45 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566598845.46.0.100568765542.issue37798@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15134 pull_request: https://github.com/python/cpython/pull/15441 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 18:39:30 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 22:39:30 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566599970.91.0.759357985067.issue37798@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 5779c536321e1405b4c17654a85b8f9221be765e by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-37798: Add C fastpath for statistics.NormalDist.inv_cdf() (GH-15266) (GH-15441) https://github.com/python/cpython/commit/5779c536321e1405b4c17654a85b8f9221be765e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 18:41:39 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 22:41:39 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566600099.32.0.639539806214.issue37798@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks for doing the work one this. Nice work :-) There's one more step. Can you please amend to the tests to run both the pure python and C versions. See Lib/test/test_heapq.py for an example of how to this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 18:58:04 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 23 Aug 2019 22:58:04 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566601084.37.0.648311527068.issue37798@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 19:22:51 2019 From: report at bugs.python.org (Dong-hee Na) Date: Fri, 23 Aug 2019 23:22:51 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566602571.59.0.518719687486.issue37798@roundup.psfhosted.org> Dong-hee Na added the comment: > There's one more step. Can you please amend to the tests to run both the > pure python and C versions. Sure, I will take look at it! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 20:20:45 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 00:20:45 +0000 Subject: [issue9985] difflib.SequenceMatcher has slightly buggy and undocumented caching behavior In-Reply-To: <1285770739.15.0.805040100323.issue9985@psf.upfronthosting.co.za> Message-ID: <1566606045.5.0.957297743084.issue9985@roundup.psfhosted.org> Raymond Hettinger added the comment: This was fixed for Python 2.7 and Python 3.4 and later. ---------- resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 20:25:31 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 00:25:31 +0000 Subject: [issue17794] Add a key parameter to PriorityQueue In-Reply-To: <1366331842.58.0.144732937336.issue17794@psf.upfronthosting.co.za> Message-ID: <1566606331.99.0.733800008801.issue17794@roundup.psfhosted.org> Raymond Hettinger added the comment: Starting in Python 3.7, dataclasses made it trivially easy to work around this issue. The PriorityQueue docs have a worked out example of how to do this: https://docs.python.org/3/library/queue.html#queue.PriorityQueue ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 20:27:29 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 00:27:29 +0000 Subject: [issue34259] Improve docstring of list.sort In-Reply-To: <1532778727.04.0.56676864532.issue34259@psf.upfronthosting.co.za> Message-ID: <1566606449.57.0.417062219429.issue34259@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 21:03:39 2019 From: report at bugs.python.org (Open Close) Date: Sat, 24 Aug 2019 01:03:39 +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: <1566608619.5.0.312903951556.issue35998@roundup.psfhosted.org> Open Close added the comment: For me, since GH-14080, It's been fixed. (arch linux) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 21:34:04 2019 From: report at bugs.python.org (Victor Milovanov) Date: Sat, 24 Aug 2019 01:34:04 +0000 Subject: [issue35235] Access violation on alloc in Windows x86-64 python, pymalloc_alloc In-Reply-To: <1542131178.89.0.788709270274.issue35235@psf.upfronthosting.co.za> Message-ID: <1566610444.02.0.340857919798.issue35235@roundup.psfhosted.org> Victor Milovanov added the comment: This reproduces stably for me when running unit tests in Python.NET project at commit 5e276d9. ---------- nosy: +Victor Milovanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 22:47:16 2019 From: report at bugs.python.org (Victor Milovanov) Date: Sat, 24 Aug 2019 02:47:16 +0000 Subject: [issue35235] Access violation on alloc in Windows x86-64 python, pymalloc_alloc In-Reply-To: <1542131178.89.0.788709270274.issue35235@psf.upfronthosting.co.za> Message-ID: <1566614836.42.0.303311755764.issue35235@roundup.psfhosted.org> Victor Milovanov added the comment: In my case it always happens in pymalloc_alloc when size == 5, e.g. when accessing usedpools[10]. Specifically freeblock pointer in usedpools[10] is waaaay off (essentially, seemingly random number looking like 0xXXXXX000) where it is supposed to be (e.g. very far from usedpools[10]). Surprisingly, all the other fields in usedpool[10] seem to have normal values. I could not find any place in obmalloc.c where this value would be set, so it seems to be a memory corruption caused by something else. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Aug 23 22:54:55 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 02:54:55 +0000 Subject: [issue19119] duplicate test name in Lib/test/test_heapq.py In-Reply-To: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za> Message-ID: <1566615295.83.0.376293299649.issue19119@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +15135 pull_request: https://github.com/python/cpython/pull/15442 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 00:29:50 2019 From: report at bugs.python.org (George Zhang) Date: Sat, 24 Aug 2019 04:29:50 +0000 Subject: [issue37461] email.parser.Parser hang In-Reply-To: <1561951273.26.0.821144691276.issue37461@roundup.psfhosted.org> Message-ID: <1566620990.13.0.98456415596.issue37461@roundup.psfhosted.org> Change by George Zhang : ---------- pull_requests: +15136 pull_request: https://github.com/python/cpython/pull/15430 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 00:30:28 2019 From: report at bugs.python.org (Ned Deily) Date: Sat, 24 Aug 2019 04:30:28 +0000 Subject: [issue37461] email.parser.Parser hang In-Reply-To: <1561951273.26.0.821144691276.issue37461@roundup.psfhosted.org> Message-ID: <1566621028.38.0.349228707096.issue37461@roundup.psfhosted.org> Ned Deily added the comment: New changeset 799e4e527019d9429fdef12d08a0c03b08a1fb59 by Ned Deily (GeeTransit) in branch '3.7': [3.7] bpo-37461: Fix typo (inifite -> infinite) (GH-15430) https://github.com/python/cpython/commit/799e4e527019d9429fdef12d08a0c03b08a1fb59 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 00:33:24 2019 From: report at bugs.python.org (George Zhang) Date: Sat, 24 Aug 2019 04:33:24 +0000 Subject: [issue37461] email.parser.Parser hang In-Reply-To: <1561951273.26.0.821144691276.issue37461@roundup.psfhosted.org> Message-ID: <1566621204.18.0.62758889053.issue37461@roundup.psfhosted.org> Change by George Zhang : ---------- pull_requests: +15137 pull_request: https://github.com/python/cpython/pull/15432 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 00:33:39 2019 From: report at bugs.python.org (Ned Deily) Date: Sat, 24 Aug 2019 04:33:39 +0000 Subject: [issue37461] email.parser.Parser hang In-Reply-To: <1561951273.26.0.821144691276.issue37461@roundup.psfhosted.org> Message-ID: <1566621219.69.0.240623260657.issue37461@roundup.psfhosted.org> Ned Deily added the comment: New changeset f1f9c0c532089824791cfc18e6d6f29e1cd62596 by Ned Deily (GeeTransit) in branch '3.6': [3.6] bpo-37461: Fix typo (inifite -> infinite) (#15432) https://github.com/python/cpython/commit/f1f9c0c532089824791cfc18e6d6f29e1cd62596 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 00:36:26 2019 From: report at bugs.python.org (Ned Deily) Date: Sat, 24 Aug 2019 04:36:26 +0000 Subject: [issue37461] email.parser.Parser hang In-Reply-To: <1561951273.26.0.821144691276.issue37461@roundup.psfhosted.org> Message-ID: <1566621386.01.0.240853117958.issue37461@roundup.psfhosted.org> Ned Deily added the comment: xtreak, would you be willing to make the PR for 3.5? That will make it easier for Larry to decide whether to include it in a 3.5 security release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 00:43:08 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 04:43:08 +0000 Subject: [issue14010] deeply nested itertools objects segfault In-Reply-To: <1329235106.54.0.737183388066.issue14010@psf.upfronthosting.co.za> Message-ID: <1566621788.92.0.645093270699.issue14010@roundup.psfhosted.org> Raymond Hettinger added the comment: [Armin] > It's just one of many places where CPython does a recursion > without checking the recursion depth. CPython still works, > based on the resonable assumption that doing such a recursion > here is obscure. I agree with that assessment and am going to close this as something we can live with (or least have lived with successfully for a long time). AFAICT, this situation doesn't arise in practical code. It is possible to slow down the language by adding a variant of recursion checks to every call to an iterator. But this just makes the language pay a code complexity cost and performance cost for something that doesn't really affect real users. People typically choose itertools for their speed (otherwise, plain generators can be clearer). We shouldn't work against the needs of those users. A robust, clean, and performant solution wouldn't be easy but would likely involve some general purpose stack overflow protection that periodically makes sure there is enough stack remaining for C Python to function correctly. ---------- resolution: -> wont fix stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 00:55:44 2019 From: report at bugs.python.org (Abhilash Raj) Date: Sat, 24 Aug 2019 04:55:44 +0000 Subject: [issue37461] email.parser.Parser hang In-Reply-To: <1561951273.26.0.821144691276.issue37461@roundup.psfhosted.org> Message-ID: <1566622544.33.0.307927918938.issue37461@roundup.psfhosted.org> Change by Abhilash Raj : ---------- pull_requests: +15138 pull_request: https://github.com/python/cpython/pull/15446 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 00:56:40 2019 From: report at bugs.python.org (Abhilash Raj) Date: Sat, 24 Aug 2019 04:56:40 +0000 Subject: [issue37461] email.parser.Parser hang In-Reply-To: <1561951273.26.0.821144691276.issue37461@roundup.psfhosted.org> Message-ID: <1566622600.59.0.795747508166.issue37461@roundup.psfhosted.org> Abhilash Raj added the comment: I manually created a backport PR for 3.5 and added Larry as a reviewer. https://github.com/python/cpython/pull/15446 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 01:31:25 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 05:31:25 +0000 Subject: [issue19119] duplicate test name in Lib/test/test_heapq.py In-Reply-To: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za> Message-ID: <1566624685.2.0.182133024854.issue19119@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 4101181fd87c2fab6456663d3c8cc99377cf0463 by Raymond Hettinger in branch 'master': bpo-19119: Remove invalid test and rename a misnamed test (GH-15442) https://github.com/python/cpython/commit/4101181fd87c2fab6456663d3c8cc99377cf0463 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 01:31:39 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 24 Aug 2019 05:31:39 +0000 Subject: [issue19119] duplicate test name in Lib/test/test_heapq.py In-Reply-To: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za> Message-ID: <1566624699.36.0.347496808539.issue19119@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15139 pull_request: https://github.com/python/cpython/pull/15447 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 01:54:10 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 05:54:10 +0000 Subject: [issue19119] duplicate test name in Lib/test/test_heapq.py In-Reply-To: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za> Message-ID: <1566626050.52.0.809770814689.issue19119@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset ef3ccd737020a0bb49ea0bfe48069f89bb5370a1 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-19119: Remove invalid test and rename a misnamed test (GH-15442) (GH-15447) https://github.com/python/cpython/commit/ef3ccd737020a0bb49ea0bfe48069f89bb5370a1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 01:56:23 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 05:56:23 +0000 Subject: [issue19119] duplicate test name in Lib/test/test_heapq.py In-Reply-To: <1380401602.68.0.29924709136.issue19119@psf.upfronthosting.co.za> Message-ID: <1566626183.96.0.620581971959.issue19119@roundup.psfhosted.org> Raymond Hettinger added the comment: Removed the bogus test -- it was a cut-and-paste error from a scratch file. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 01:56:48 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 24 Aug 2019 05:56:48 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1566626208.63.0.60584223646.issue37812@roundup.psfhosted.org> Change by Greg Price : ---------- pull_requests: +15140 pull_request: https://github.com/python/cpython/pull/15448 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 02:01:20 2019 From: report at bugs.python.org (Vinay Sharma) Date: Sat, 24 Aug 2019 06:01:20 +0000 Subject: [issue37754] Persistence of Shared Memory Segment after process exits In-Reply-To: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> Message-ID: <1566626480.34.0.951719465981.issue37754@roundup.psfhosted.org> Change by Vinay Sharma : ---------- versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 02:05:00 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 24 Aug 2019 06:05:00 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1566626700.73.0.76039930717.issue37812@roundup.psfhosted.org> Greg Price added the comment: Thanks, Raymond, for the review on GH-15216! Shortly after posting this issue, I noticed a very similar story in CHECK_BINOP. I've just posted GH-15448 to similarly make returns explicit there. It basically consists of a number of repetitions of - CHECK_BINOP(self, other); + if (!PyLong_Check(self) || !PyLong_Check(other)) { + Py_RETURN_NOTIMPLEMENTED; + } with the names `self` and `other` varying from site to site. Though the expanded version isn't literally a `return` statement, I think it functions almost as well as one for the purposes that explicitness serves here, and much better so than a reference to `CHECK_BINOP`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 02:14:39 2019 From: report at bugs.python.org (Kyle Stanley) Date: Sat, 24 Aug 2019 06:14:39 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1566627279.7.0.620753911209.issue37812@roundup.psfhosted.org> Kyle Stanley added the comment: > python-dev likely isn't the right place. That is a forum for more mature ideas. Agreed, that idea should be posted to python-list if they're having issues posting to python-ideas. Python-dev certainly wouldn't be appropriate for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 02:27:42 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 06:27:42 +0000 Subject: [issue32118] Doc for comparison of sequences with non-orderable elements In-Reply-To: <1511411221.22.0.213398074469.issue32118@psf.upfronthosting.co.za> Message-ID: <1566628062.12.0.713120535825.issue32118@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +15141 pull_request: https://github.com/python/cpython/pull/15450 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 02:31:41 2019 From: report at bugs.python.org (Shai) Date: Sat, 24 Aug 2019 06:31:41 +0000 Subject: [issue37935] Improve performance of pathlib.scandir() Message-ID: <1566628301.14.0.386871182456.issue37935@roundup.psfhosted.org> New submission from Shai : I recently have taken a look in the source code of the pathlib module, and I saw something weird there: when the module used the scandir function, it first converted its iterator into a list and then used it in a for loop. The list wasn't used anywhere else, so I think the conversion to list is just a waste of performance. In addition, I noticed that the scandir iterator is never closed (it's not used in a with statement and its close method isn't called). I know that the iterator is closed automatically when it's garbaged collected, but according to the docs, it's advisable to close it explicitly. I've created a pull request that fixes these issues: PR 15331 In the PR, I changed the code so the scandir iterator is used directly instead of being converted into a list and I wrapped its usage in a with statement to close resources properly. ---------- components: Library (Lib) messages: 350354 nosy: Shai priority: normal pull_requests: 15142 severity: normal status: open title: Improve performance of pathlib.scandir() type: performance versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 02:34:10 2019 From: report at bugs.python.org (Kyle Stanley) Date: Sat, 24 Aug 2019 06:34:10 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1566628450.56.0.613807331556.issue37812@roundup.psfhosted.org> Change by Kyle Stanley : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 03:15:12 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 24 Aug 2019 07:15:12 +0000 Subject: [issue37936] gitignore file is too broad Message-ID: <1566630912.92.0.00349300289224.issue37936@roundup.psfhosted.org> New submission from Greg Price : There are a number of files that we track in the repo, but are nevertheless covered by `.gitignore`. This *mostly* doesn't change anything, because Git itself only cares what `.gitignore` has to say about files that aren't already tracked. But: * It affects any new files someone might add that are covered by the same unintentionally-broad patterns. In that case it'd be likely to cause some confused debugging into why Git wasn't seeing the file; or possibly loss of work, if the person didn't notice that the file had never been committed to Git. * More immediately, other tools that aren't Git but consult the Git ignore rules don't necessarily implement this wrinkle. In particular this is unfortunately a WONTFIX bug in ripgrep / `rg`: https://github.com/BurntSushi/ripgrep/issues/1127 . I learned of the `rg` bug (and, for that matter, refreshed myself on just how Git itself handles this case) after some confusion today where I was looking with for references to a given macro, thought I'd looked at all of them... and then later noticed through `git log -p -S` a reference in `PC/pyconfig.h` with no subsequent change deleting it. Turned out it was indeed there and I needed to take account of it. Here's the list of affected files: $ git ls-files -i --exclude-standard .gitignore Doc/Makefile Lib/test/data/README Modules/Setup PC/pyconfig.h Tools/freeze/test/Makefile Tools/msi/core/core.wixproj Tools/msi/core/core.wxs Tools/msi/core/core_d.wixproj Tools/msi/core/core_d.wxs Tools/msi/core/core_en-US.wxl Tools/msi/core/core_files.wxs Tools/msi/core/core_pdb.wixproj Tools/msi/core/core_pdb.wxs Tools/unicode/Makefile Fortunately this is not hard to fix. The semantics of `.gitignore` have a couple of gotchas, but once you know them it's not really any more complicated to get the behavior exactly right. And I've previously spent the hour or two to read up on it... and when I forget, I just consult my own short notes :), at the top of this file: https://github.com/zulip/zulip/blob/master/.gitignore I have a minimal fix which takes care of all the files above. I'll post that shortly, and I may also write up a more thorough fix that tries to make it easy not to fall into the same Git pitfall again. ---------- components: Build messages: 350355 nosy: Greg Price priority: normal severity: normal status: open title: gitignore file is too broad versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 03:30:06 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 24 Aug 2019 07:30:06 +0000 Subject: [issue37936] gitignore file is too broad In-Reply-To: <1566630912.92.0.00349300289224.issue37936@roundup.psfhosted.org> Message-ID: <1566631806.88.0.892030601285.issue37936@roundup.psfhosted.org> Change by Greg Price : ---------- keywords: +patch pull_requests: +15143 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15451 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 03:36:14 2019 From: report at bugs.python.org (SilentGhost) Date: Sat, 24 Aug 2019 07:36:14 +0000 Subject: [issue37935] Improve performance of pathlib.scandir() In-Reply-To: <1566628301.14.0.386871182456.issue37935@roundup.psfhosted.org> Message-ID: <1566632174.21.0.72005377449.issue37935@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +pitrou stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 04:17:27 2019 From: report at bugs.python.org (Tal Einat) Date: Sat, 24 Aug 2019 08:17:27 +0000 Subject: [issue37929] IDLE: OK sometimes fails to close configdialog In-Reply-To: <1566566864.85.0.308464800085.issue37929@roundup.psfhosted.org> Message-ID: <1566634647.89.0.796244805185.issue37929@roundup.psfhosted.org> Change by Tal Einat : ---------- keywords: +patch pull_requests: +15144 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15452 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 04:19:11 2019 From: report at bugs.python.org (Tal Einat) Date: Sat, 24 Aug 2019 08:19:11 +0000 Subject: [issue37929] IDLE: OK sometimes fails to close configdialog In-Reply-To: <1566566864.85.0.308464800085.issue37929@roundup.psfhosted.org> Message-ID: <1566634751.07.0.800295424081.issue37929@roundup.psfhosted.org> Tal Einat added the comment: See PR GH-15452 with a fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 04:36:28 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sat, 24 Aug 2019 08:36:28 +0000 Subject: [issue37797] Add name attribute to NameError In-Reply-To: <1565310615.1.0.816641824281.issue37797@roundup.psfhosted.org> Message-ID: <1566635788.63.0.787843446619.issue37797@roundup.psfhosted.org> Change by Dong-hee Na : ---------- keywords: +patch pull_requests: +15145 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15453 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 04:36:55 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sat, 24 Aug 2019 08:36:55 +0000 Subject: [issue37797] Add name attribute to NameError In-Reply-To: <1565310615.1.0.816641824281.issue37797@roundup.psfhosted.org> Message-ID: <1566635815.78.0.204674390662.issue37797@roundup.psfhosted.org> Change by Dong-hee Na : ---------- pull_requests: -15145 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 04:37:47 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sat, 24 Aug 2019 08:37:47 +0000 Subject: [issue37797] Add name attribute to NameError In-Reply-To: <1565310615.1.0.816641824281.issue37797@roundup.psfhosted.org> Message-ID: <1566635867.56.0.688007007988.issue37797@roundup.psfhosted.org> Change by Dong-hee Na : ---------- pull_requests: +15147 pull_request: https://github.com/python/cpython/pull/15453 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 04:37:47 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sat, 24 Aug 2019 08:37:47 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566635867.49.0.685304595343.issue37798@roundup.psfhosted.org> Change by Dong-hee Na : ---------- pull_requests: +15146 pull_request: https://github.com/python/cpython/pull/15453 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 04:56:28 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Sat, 24 Aug 2019 08:56:28 +0000 Subject: [issue37934] Docs: Clarify NotImplemented use cases In-Reply-To: <1566596946.3.0.57144717386.issue37934@roundup.psfhosted.org> Message-ID: <1566636988.12.0.46968549939.issue37934@roundup.psfhosted.org> Change by Jeroen Demeyer : ---------- nosy: +jdemeyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 05:49:30 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Aug 2019 09:49:30 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1566640170.33.0.194895413275.issue29535@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset e9c90aa43144b0be1e4e393e8cb549573437a5da by Serhiy Storchaka in branch 'master': bpo-29535: Remove promize about hash randomization of datetime objects. (GH-15269) https://github.com/python/cpython/commit/e9c90aa43144b0be1e4e393e8cb549573437a5da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 05:49:43 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 24 Aug 2019 09:49:43 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1566640183.38.0.965330727823.issue29535@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15148 pull_request: https://github.com/python/cpython/pull/15454 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:00:35 2019 From: report at bugs.python.org (Ram Rachum) Date: Sat, 24 Aug 2019 10:00:35 +0000 Subject: [issue37937] Mention ``frame.f_trace`` in :func:`sys.settrace` docs. Message-ID: <1566640835.5.0.307491692572.issue37937@roundup.psfhosted.org> Change by Ram Rachum : ---------- assignee: docs at python components: Documentation nosy: cool-RR, docs at python priority: normal pull_requests: 15149 severity: normal status: open title: Mention ``frame.f_trace`` in :func:`sys.settrace` docs. type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:09:40 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Aug 2019 10:09:40 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566641380.85.0.479847824834.issue37884@roundup.psfhosted.org> Serhiy Storchaka added the comment: > I'm with Raymond here; I don't think this change is desirable for the math module, either with or without the leading underscore in the name. Could you please explain what is wrong in adding a helper function which will help to convert different types of numbers to integer ratio correctly? Currently you need to write a complex code if you need to convert a general number to integer ratio: try: as_integer_ratio = x.as_integer_ratio except AttributeError: n = x.numerator d = x.denominator else: n, d = as_integer_ratio() (and maybe even more complex if you want to add fast path for int). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:11:29 2019 From: report at bugs.python.org (hai shi) Date: Sat, 24 Aug 2019 10:11:29 +0000 Subject: [issue37908] Add some examples of ArgumentParser.exit() In-Reply-To: <1566407493.49.0.869927821626.issue37908@roundup.psfhosted.org> Message-ID: <1566641489.44.0.0813141375422.issue37908@roundup.psfhosted.org> Change by hai shi : ---------- keywords: +patch pull_requests: +15150 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15455 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:11:55 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Aug 2019 10:11:55 +0000 Subject: [issue37830] continue and break in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1566641515.47.0.55962652897.issue37830@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset ef61c524ddeeb56da3858b86e349e7288d68178e by Serhiy Storchaka in branch 'master': bpo-37830: Fix compilation of break and continue in finally. (GH-15320) https://github.com/python/cpython/commit/ef61c524ddeeb56da3858b86e349e7288d68178e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:16:26 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Aug 2019 10:16:26 +0000 Subject: [issue37830] continue and break in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1566641786.16.0.867011555766.issue37830@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +15151 pull_request: https://github.com/python/cpython/pull/15456 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:17:18 2019 From: report at bugs.python.org (hai shi) Date: Sat, 24 Aug 2019 10:17:18 +0000 Subject: [issue37908] Add some examples of ArgumentParser.exit() In-Reply-To: <1566407493.49.0.869927821626.issue37908@roundup.psfhosted.org> Message-ID: <1566641838.0.0.563786773757.issue37908@roundup.psfhosted.org> hai shi added the comment: Adding an example of ArgumentParser.exit(), because some user would like cathing errors manually or consider exit progress or not when an error occurs. I have not add example of ArgumentParser.error(), because i can not think some user scenarios:( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:17:37 2019 From: report at bugs.python.org (hai shi) Date: Sat, 24 Aug 2019 10:17:37 +0000 Subject: [issue37908] Add an example of ArgumentParser.exit() In-Reply-To: <1566407493.49.0.869927821626.issue37908@roundup.psfhosted.org> Message-ID: <1566641857.21.0.758497159009.issue37908@roundup.psfhosted.org> Change by hai shi : ---------- title: Add some examples of ArgumentParser.exit() -> Add an example of ArgumentParser.exit() type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:19:54 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 24 Aug 2019 10:19:54 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1566641993.99.0.592726429807.issue29535@roundup.psfhosted.org> miss-islington added the comment: New changeset 076d0b9f5def35aeb0f8e8aadf658dc35aace81d by Miss Islington (bot) in branch '3.8': bpo-29535: Remove promize about hash randomization of datetime objects. (GH-15269) https://github.com/python/cpython/commit/076d0b9f5def35aeb0f8e8aadf658dc35aace81d ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:22:17 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 24 Aug 2019 10:22:17 +0000 Subject: [issue28269] [MinGW] Can't compile Python/dynload_win.c due to static strcasecmp In-Reply-To: <1474800483.31.0.700864577383.issue28269@psf.upfronthosting.co.za> Message-ID: <1566642137.54.0.0571529995687.issue28269@roundup.psfhosted.org> miss-islington added the comment: New changeset 920ec4b7763d64b3742d7ddd339ad11cdbec62e9 by Miss Islington (bot) in branch '3.8': bpo-28269: Replace strcasecmp with system function _stricmp. (GH-13095) https://github.com/python/cpython/commit/920ec4b7763d64b3742d7ddd339ad11cdbec62e9 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:22:52 2019 From: report at bugs.python.org (hai shi) Date: Sat, 24 Aug 2019 10:22:52 +0000 Subject: [issue37908] Add an example of ArgumentParser.exit() In-Reply-To: <1566407493.49.0.869927821626.issue37908@roundup.psfhosted.org> Message-ID: <1566642172.92.0.590491537475.issue37908@roundup.psfhosted.org> Change by hai shi : ---------- nosy: +bethard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:29:35 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Aug 2019 10:29:35 +0000 Subject: [issue29535] datetime hash is deterministic in some cases In-Reply-To: <1486826213.38.0.893503150194.issue29535@psf.upfronthosting.co.za> Message-ID: <1566642575.15.0.4526957859.issue29535@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python resolution: -> fixed stage: patch review -> resolved status: open -> closed type: security -> behavior versions: -Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:31:25 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Aug 2019 10:31:25 +0000 Subject: [issue28269] [MinGW] Can't compile Python/dynload_win.c due to static strcasecmp In-Reply-To: <1474800483.31.0.700864577383.issue28269@psf.upfronthosting.co.za> Message-ID: <1566642685.94.0.861504022944.issue28269@roundup.psfhosted.org> Serhiy Storchaka added the comment: Thank you for your PR Minmin. It was decided to not backport it to 3.7. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:41:56 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Aug 2019 10:41:56 +0000 Subject: [issue37830] continue and break in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1566643316.76.0.956106475557.issue37830@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset ed146b52a3b6537689324e3bd9952055f9c6b43d by Serhiy Storchaka in branch '3.8': [3.8] bpo-37830: Fix compilation of break and continue in finally. (GH-15320) (GH-15456) https://github.com/python/cpython/commit/ed146b52a3b6537689324e3bd9952055f9c6b43d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 06:57:26 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 24 Aug 2019 10:57:26 +0000 Subject: [issue37830] continue and break in finally with return in try results with segfault In-Reply-To: <1565602413.18.0.439989203772.issue37830@roundup.psfhosted.org> Message-ID: <1566644246.57.0.778964222245.issue37830@roundup.psfhosted.org> Serhiy Storchaka added the comment: For forbidding 'break', 'continue' and 'return' in the 'finally' clause please open a topic on Python-Dev. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 07:25:57 2019 From: report at bugs.python.org (Pradyun Gedam) Date: Sat, 24 Aug 2019 11:25:57 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566645957.29.0.0895988491617.issue37664@roundup.psfhosted.org> Pradyun Gedam added the comment: There's a need for a pip 19.2.3, since there's a bug in wheel tagging logic hasn't been updated for CPython 3.8's new tags. I'll be cutting that release, and filing a PR for updating bundled pip & setuptools, sometime in the next 24 hours. (I just got back from my final mid-semester exam, and really should relax for a bit) I'm not sure whether we should mark this a release blocker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 07:28:50 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Sat, 24 Aug 2019 11:28:50 +0000 Subject: [issue37938] refactor PyLong_As*() functions Message-ID: <1566646130.69.0.631400652637.issue37938@roundup.psfhosted.org> New submission from Sergey Fedoseev : PyLong_As*() functions have a lot of duplicated code, creating draft PR with attempt to deduplicate them. ---------- components: Interpreter Core messages: 350367 nosy: sir-sigurd priority: normal severity: normal status: open title: refactor PyLong_As*() functions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 07:29:37 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Sat, 24 Aug 2019 11:29:37 +0000 Subject: [issue37938] refactor PyLong_As*() functions In-Reply-To: <1566646130.69.0.631400652637.issue37938@roundup.psfhosted.org> Message-ID: <1566646177.13.0.401316667819.issue37938@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- keywords: +patch pull_requests: +15152 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15457 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 07:29:29 2019 From: report at bugs.python.org (Batuhan) Date: Sat, 24 Aug 2019 11:29:29 +0000 Subject: [issue36946] Possible signed integer overflow in slice handling In-Reply-To: <1558072124.41.0.0531416904304.issue36946@roundup.psfhosted.org> Message-ID: <1566646169.75.0.686926019368.issue36946@roundup.psfhosted.org> Batuhan added the comment: Should we close this? ---------- nosy: +BTaskaya _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 07:32:25 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 24 Aug 2019 11:32:25 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566646345.11.0.376670493781.issue37664@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Added lukasz since last beta is by Monday. ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 07:35:54 2019 From: report at bugs.python.org (Batuhan) Date: Sat, 24 Aug 2019 11:35:54 +0000 Subject: [issue37925] --embed not included in python3.8-config usage/--help In-Reply-To: <1566539578.53.0.511767507414.issue37925@roundup.psfhosted.org> Message-ID: <1566646554.34.0.812006605451.issue37925@roundup.psfhosted.org> Change by Batuhan : ---------- keywords: +patch pull_requests: +15153 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15458 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 07:44:27 2019 From: report at bugs.python.org (Batuhan) Date: Sat, 24 Aug 2019 11:44:27 +0000 Subject: [issue19867] pickletools.OpcodeInfo.code is a string In-Reply-To: <1386024237.29.0.240373861832.issue19867@psf.upfronthosting.co.za> Message-ID: <1566647067.25.0.708764623103.issue19867@roundup.psfhosted.org> Batuhan added the comment: What should we do then, close? ---------- nosy: +BTaskaya _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 10:34:03 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sat, 24 Aug 2019 14:34:03 +0000 Subject: [issue37797] Add name attribute to NameError In-Reply-To: <1565310615.1.0.816641824281.issue37797@roundup.psfhosted.org> Message-ID: <1566657243.08.0.297322260424.issue37797@roundup.psfhosted.org> Change by Dong-hee Na : ---------- pull_requests: -15147 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 10:54:52 2019 From: report at bugs.python.org (Yugi) Date: Sat, 24 Aug 2019 14:54:52 +0000 Subject: [issue37939] os.path.normpath change some characters of a path into kinda 'hex number' Message-ID: <1566658492.51.0.598061763854.issue37939@roundup.psfhosted.org> New submission from Yugi : I was trying to handle path to work on both '/' and '\' but when I tried to run the code like they said on: https://stackoverflow.com/questions/3167154/how-to-split-a-dos-path-into-its-components-in-python I have no idea why the terminal on my PC doesnt have the same output like everybody was discussing at the time the questions and answers were posted. OS: ubuntu 16.04 LTS, Intel Core i5-7500, 16GB/1TB, Intel HD Graphics 630 python version: 3.5.2 I borrowed a mac pro 2015 to check if it had the same output like my PC but it had not. my friend has python 3.7.1 installed and the output is: ['d:\\stuff\\morestuff\\furtherdown\\THEFILE.txt'] (on my PC, it is: ['d:\\stuff\\morestuff\x0curtherdown\\THEFILE.txt']). I'm totally new to Python and I'm very sorry if this issue is already reported. Thank you! ---------- files: Screenshot from 2019-08-24 21-41-52.png messages: 350371 nosy: Yugi priority: normal severity: normal status: open title: os.path.normpath change some characters of a path into kinda 'hex number' type: behavior versions: Python 3.5 Added file: https://bugs.python.org/file48560/Screenshot from 2019-08-24 21-41-52.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 10:55:33 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 24 Aug 2019 14:55:33 +0000 Subject: [issue37940] Add xml.tool to pretty print XML like json.tool Message-ID: <1566658533.41.0.722111821042.issue37940@roundup.psfhosted.org> New submission from Karthikeyan Singaravelan : Now that XML has pretty print option with issue14465 would it be handy to add a command line tool pretty printer similar to json.tool? This can be written as one-liner similar to json pretty printing but I think it's a good option and having a command line tool also helps in piping the output to other commands like filtering particular tags. I tried searching mailing list and couldn't find any discussions along these lines. There were some concerns around using external tools and in https://bugs.python.org/issue14465#msg324098 . I thought to open this to gather feedback. Branch : https://github.com/tirkarthi/cpython/tree/bpo14465-xml-tool python -m xml.tool /tmp/person.xml Idly Dosa # Get all breakfast tags python -m xml.tool /tmp/person.xml | grep breakfast Idly Dosa ---------- components: Library (Lib) messages: 350372 nosy: eli.bendersky, rhettinger, scoder, serhiy.storchaka, xtreak priority: normal severity: normal status: open title: Add xml.tool to pretty print XML like json.tool type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 11:03:42 2019 From: report at bugs.python.org (Vinay Sharma) Date: Sat, 24 Aug 2019 15:03:42 +0000 Subject: [issue37754] Persistence of Shared Memory Segment after process exits In-Reply-To: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> Message-ID: <1566659022.57.0.0928680291498.issue37754@roundup.psfhosted.org> Change by Vinay Sharma : ---------- keywords: +patch pull_requests: +15154 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15460 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 11:07:55 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sat, 24 Aug 2019 15:07:55 +0000 Subject: [issue37939] os.path.normpath change some characters of a path into kinda 'hex number' In-Reply-To: <1566658492.51.0.598061763854.issue37939@roundup.psfhosted.org> Message-ID: <1566659275.7.0.21940549284.issue37939@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: I guess '\f' translates to \x0c and using raw string helps with this. >>> ord('\f') 12 >>> '\f' '\x0c' >>> var = "d:\stuff\morestuff\furtherdown\THEFILE.txt" >>> var 'd:\\stuff\\morestuff\x0curtherdown\\THEFILE.txt' >>> print(os.path.normpath(var)) d:\stuff\morestuff urtherdown\THEFILE.txt >>> os.path.normpath(var) 'd:\\stuff\\morestuff\x0curtherdown\\THEFILE.txt' # Use raw string >>> var = r"d:\stuff\morestuff\furtherdown\THEFILE.txt" >>> var 'd:\\stuff\\morestuff\\furtherdown\\THEFILE.txt' >>> print(os.path.normpath(var)) d:\stuff\morestuff\furtherdown\THEFILE.txt >>> os.path.normpath(var) 'd:\\stuff\\morestuff\\furtherdown\\THEFILE.txt' # Or escape back slashes >>> var = "d:\\stuff\\morestuff\\furtherdown\\THEFILE.txt" >>> var 'd:\\stuff\\morestuff\\furtherdown\\THEFILE.txt' >>> print(os.path.normpath(var)) d:\stuff\morestuff\furtherdown\THEFILE.txt ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 11:26:44 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 24 Aug 2019 15:26:44 +0000 Subject: [issue37772] zipfile.Path.iterdir() outputs sub directories many times or not at all In-Reply-To: <1565074650.65.0.762547380277.issue37772@roundup.psfhosted.org> Message-ID: <1566660404.55.0.375462871108.issue37772@roundup.psfhosted.org> Jason R. Coombs added the comment: New changeset a4e2991bdc993b60b6457c8a38d6e4a1fc845781 by Jason R. Coombs (shireenrao) in branch 'master': bpo-37772: fix zipfile.Path.iterdir() outputs (GH-15170) https://github.com/python/cpython/commit/a4e2991bdc993b60b6457c8a38d6e4a1fc845781 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 11:30:25 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 24 Aug 2019 15:30:25 +0000 Subject: [issue37772] zipfile.Path.iterdir() outputs sub directories many times or not at all In-Reply-To: <1565074650.65.0.762547380277.issue37772@roundup.psfhosted.org> Message-ID: <1566660625.33.0.538491609212.issue37772@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15155 pull_request: https://github.com/python/cpython/pull/15461 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 12:03:55 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 24 Aug 2019 16:03:55 +0000 Subject: [issue37772] zipfile.Path.iterdir() outputs sub directories many times or not at all In-Reply-To: <1565074650.65.0.762547380277.issue37772@roundup.psfhosted.org> Message-ID: <1566662635.61.0.482462901969.issue37772@roundup.psfhosted.org> Jason R. Coombs added the comment: New changeset c410f381bf66c48d84812e19e3ba7c2878511a3e by Jason R. Coombs (Miss Islington (bot)) in branch '3.8': bpo-37772: fix zipfile.Path.iterdir() outputs (GH-15170) (#15461) https://github.com/python/cpython/commit/c410f381bf66c48d84812e19e3ba7c2878511a3e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 12:28:26 2019 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 24 Aug 2019 16:28:26 +0000 Subject: [issue37772] zipfile.Path.iterdir() outputs sub directories many times or not at all In-Reply-To: <1565074650.65.0.762547380277.issue37772@roundup.psfhosted.org> Message-ID: <1566664106.12.0.209450083555.issue37772@roundup.psfhosted.org> Jason R. Coombs added the comment: Thanks very much shireenrao for the PR, which is now merged with Python 3.8+. I've additionally backported the fix to zipp in 0.6.0. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 12:30:46 2019 From: report at bugs.python.org (Srinivas Nyayapati) Date: Sat, 24 Aug 2019 16:30:46 +0000 Subject: [issue33694] test_asyncio: test_start_tls_server_1() fails on Python on x86 Windows7 3.7 and 3.x In-Reply-To: <1527679178.26.0.682650639539.issue33694@psf.upfronthosting.co.za> Message-ID: <1566664246.77.0.248026550799.issue33694@roundup.psfhosted.org> Change by Srinivas Nyayapati : ---------- pull_requests: +15156 pull_request: https://github.com/python/cpython/pull/15170 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 12:53:51 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 24 Aug 2019 16:53:51 +0000 Subject: [issue37940] Add xml.tool to pretty print XML like json.tool In-Reply-To: <1566658533.41.0.722111821042.issue37940@roundup.psfhosted.org> Message-ID: <1566665631.55.0.501551676686.issue37940@roundup.psfhosted.org> Stefan Behnel added the comment: Sounds like a good idea to add something like this. Have a look here for some more ideas: https://github.com/lxml/lxml/blob/master/tools/xpathgrep.py ElementTree should be able to provide most of these features as well these days. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:03:27 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 17:03:27 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1566666207.02.0.399952171238.issue37812@roundup.psfhosted.org> Raymond Hettinger added the comment: > I noticed a very similar story in CHECK_BINOP. How about we don't do any more of these :-) I understand the desire to have an explicit return but don't think these minor aesthetics are worth it. The existing code was correct. The patches increase the total code volume. There are subtle differences during the transformation (macros don't require type declarations). They are a bit tedious to review and are eating up our time in the back and forth. All changes like this risk introducing bugs into otherwise correct code. Minor code churn is rarely worth it. May I suggest directing your efforts towards fixing known bugs or implementing requested features. It isn't our goal to create more work for one another ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:12:47 2019 From: report at bugs.python.org (Vinay Sharma) Date: Sat, 24 Aug 2019 17:12:47 +0000 Subject: [issue37754] Consistency of Unix's shared_memory implementation with windows In-Reply-To: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> Message-ID: <1566666767.78.0.731448676216.issue37754@roundup.psfhosted.org> Vinay Sharma added the comment: Hi, I just opened a PR implementing a fix very similar to your suggestions. I am using advisory locking using fcntl.flock. And I am locking on file descriptors. If you see my PR, in resource tracker I am opening a file "/dev/shm/", and trying to acquire exclusive lock on the same. And it's working great on Linux. Since, resource_tracker is spawned as a different process, I can't directly use file descriptors. But macOS doesn't have any memory mapped files created by shm_open in /dev/shm. In fact, it doesn't store any reference to memory mapped files in the filesystem. Therefore it get's difficult to get the file descriptor in resource tracker. Also, is there a good way to pass file descriptors between processes. Any ideas on the above issue will be much appreciated. ---------- title: Persistence of Shared Memory Segment after process exits -> Consistency of Unix's shared_memory implementation with windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:19:40 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 17:19:40 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1566667180.45.0.0691316182637.issue37812@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 5e63ab05f114987478a21612d918a1c0276fe9d2 by Raymond Hettinger (Greg Price) in branch 'master': bpo-37812: Convert CHECK_SMALL_INT macro to a function so the return is explicit. (GH-15216) https://github.com/python/cpython/commit/5e63ab05f114987478a21612d918a1c0276fe9d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:19:57 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 17:19:57 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1566667197.52.0.839670368043.issue37812@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:24:33 2019 From: report at bugs.python.org (Vinay Sharma) Date: Sat, 24 Aug 2019 17:24:33 +0000 Subject: [issue37754] Consistency of Unix's shared_memory implementation with windows In-Reply-To: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> Message-ID: <1566667473.19.0.123419612594.issue37754@roundup.psfhosted.org> Vinay Sharma added the comment: Also, shm_open returns an integer file descriptor. And when this file descriptor is passed too fcntl.flock (in macOS) it throws the following error: OSError: [Errno 45] Operation not supported Whereas, the same code works fine on linux. Therefore, I have doubts whether Macos flock implementation support locking shared_memory files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:31:18 2019 From: report at bugs.python.org (Eryk Sun) Date: Sat, 24 Aug 2019 17:31:18 +0000 Subject: [issue37939] os.path.normpath change some characters of a path into kinda 'hex number' In-Reply-To: <1566658492.51.0.598061763854.issue37939@roundup.psfhosted.org> Message-ID: <1566667878.66.0.412044220083.issue37939@roundup.psfhosted.org> Eryk Sun added the comment: As Karthikeyan noted, in a regular string literal, backslash is an escape character that's used in the following escape sequences: \N{name} : named character \UXXXXXXXX : 32-bit hexadecimal ordinal (e.g. \U0010ffff) \uXXXX : 16-bit hexadecimal ordinal (e.g. \uffff) \xXX : 8-bit hexadecimal ordinal (e.g. \xff) \OOO : 9-bit octal ordinal (e.g. \777) \OO : 6-bit octal ordinal (e.g. \77) \O : 3-bit octal ordinal (e.g. \7) \a : \x07, \N{BEL}, \N{ALERT} \b : \x08, \N{BS}, \N{BACKSPACE} \t : \x09, \N{HT}, \N{TAB}, \N{CHARACTER TABULATION}, \N{HORIZONTAL TABULATION} \n : \x0a, \N{LF}, \N{NL}, \N{LINE FEED}, \N{NEW LINE} \v : \x0b, \N{VT}, \N{LINE TABULATION}, \N{VERTICAL TABULATION} \f : \x0c, \N{FF}, \N{FORM FEED} \r : \x0d, \N{CR}, \N{CARRIAGE RETURN} \" : \x22, \N{QUOTATION MARK} \' : \x27, \N{APOSTROPHE} \\ : \x5c, \N{REVERSE SOLIDUS} For a Windows path, either we can use a normal string literal with backslash path separators escaped by doubling them or we can use a raw string literal. One corner case with a raw string literal is that it can't end with an odd number of backslashes. We can address this in one of two ways. Either rely on the compiler's implicit concatenation of string literals, or rely on the system's path normalization to collapse multiple path separators (except at the beginning of a path). For example: >>> print(r'C:\Users' '\\') C:\Users\ >>> print(r'C:\Users\\') C:\Users\\ The system normalizes the second case to collapse repeated backslashes. For example: >>> print(os.path._getfullpathname(r'C:\Users\\')) C:\Users\ >>> os.path.samefile(r'C:\Users\\', r'C:\Users' '\\') True We can also use forward slash as the path separator for file-system paths (but not registry paths), such as paths that we're passing to open() or os functions. I don't recommend this if a file-system path is to be passed as a command-line argument. Some programs use forward slash as a switch for command-line options. In this case first normalize the path via os.path.normpath, or via replace('/', '\\'). In some cases a path may be returned to us in Windows with a "\\?\" prefix (backslash only), which is sometimes referred to as an extended path. (More specifically, it's a native path in the device namespace.) This tells the Windows API to skip path normalization. If a path begins with exactly this prefix, then appending components to it with forward slash results in a path that will not work. Use os.path.join, or normalize the path via os.path.normpath to ensure the final path uses only backslash as the path separator. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:42:52 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 17:42:52 +0000 Subject: [issue14112] tutorial intro talks of "shallow copy" concept without explanation In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za> Message-ID: <1566668572.12.0.312877586058.issue14112@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +15157 pull_request: https://github.com/python/cpython/pull/15465 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:43:57 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 17:43:57 +0000 Subject: [issue32118] Doc for comparison of sequences with non-orderable elements In-Reply-To: <1511411221.22.0.213398074469.issue32118@psf.upfronthosting.co.za> Message-ID: <1566668637.99.0.420916595432.issue32118@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset edd21129dd304e178ca8be82ba689488dfb58276 by Raymond Hettinger in branch 'master': bpo-32118: Simplify docs for sequence comparison (GH-15450) https://github.com/python/cpython/commit/edd21129dd304e178ca8be82ba689488dfb58276 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:44:05 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 24 Aug 2019 17:44:05 +0000 Subject: [issue32118] Doc for comparison of sequences with non-orderable elements In-Reply-To: <1511411221.22.0.213398074469.issue32118@psf.upfronthosting.co.za> Message-ID: <1566668645.32.0.821567513122.issue32118@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15158 pull_request: https://github.com/python/cpython/pull/15466 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:51:25 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 17:51:25 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566669085.98.0.101245736562.issue37798@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 8ad22a42267d4ecb1c080d420933680cc126363e by Raymond Hettinger (Dong-hee Na) in branch 'master': bpo-37798: Test both Python and C versions in test_statistics.py (GH-15453) https://github.com/python/cpython/commit/8ad22a42267d4ecb1c080d420933680cc126363e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:51:31 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 24 Aug 2019 17:51:31 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566669091.5.0.478924183611.issue37798@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15159 pull_request: https://github.com/python/cpython/pull/15467 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:53:11 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 17:53:11 +0000 Subject: [issue32118] Doc for comparison of sequences with non-orderable elements In-Reply-To: <1511411221.22.0.213398074469.issue32118@psf.upfronthosting.co.za> Message-ID: <1566669191.89.0.729163034847.issue32118@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 0ad85681de639792751ea53ec964d87d4ad45d71 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-32118: Simplify docs for sequence comparison (GH-15450) (#15466) https://github.com/python/cpython/commit/0ad85681de639792751ea53ec964d87d4ad45d71 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:53:33 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 17:53:33 +0000 Subject: [issue32118] Doc for comparison of sequences with non-orderable elements In-Reply-To: <1511411221.22.0.213398074469.issue32118@psf.upfronthosting.co.za> Message-ID: <1566669213.79.0.296048381019.issue32118@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:58:16 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 17:58:16 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566669496.37.0.744776579147.issue37798@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:58:58 2019 From: report at bugs.python.org (Eryk Sun) Date: Sat, 24 Aug 2019 17:58:58 +0000 Subject: [issue37939] os.path.normpath change some characters of a path into kinda 'hex number' In-Reply-To: <1566658492.51.0.598061763854.issue37939@roundup.psfhosted.org> Message-ID: <1566669538.49.0.937772359505.issue37939@roundup.psfhosted.org> Eryk Sun added the comment: > \N{name} : named character > \UXXXXXXXX : 32-bit hexadecimal ordinal (e.g. \U0010ffff) > \uXXXX : 16-bit hexadecimal ordinal (e.g. \uffff) > \xXX : 8-bit hexadecimal ordinal (e.g. \xff) > \OOO : 9-bit octal ordinal (e.g. \777) > \OO : 6-bit octal ordinal (e.g. \77) > \O : 3-bit octal ordinal (e.g. \7) Note that bytes literals do not implement \N, \U, and \u escape sequences -- e.g. b'\N{SPACE}' is literally just those 9 bytes, not b' '. Also, in bytes literals 9-bit octal sequences wrap around for the [256, 511] range -- e.g. b'\400' == b'\000' == b'\x00' and b'\777' == b'\377' == b'\xff'. I don't know whether the latter is intentional. I'd prefer for the compiler to raise a syntax error in this case. Asking for a byte value in the range [256, 511] is nonsense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 13:59:15 2019 From: report at bugs.python.org (Julian Berman) Date: Sat, 24 Aug 2019 17:59:15 +0000 Subject: [issue37941] python -m and runpy.run_module set different __name__ by default Message-ID: <1566669555.03.0.62423685183.issue37941@roundup.psfhosted.org> New submission from Julian Berman : This seems brutally simple, to the point where I'm concerned I'm missing something (or have seen this issue filed elsewhere but can't find it), but `python -m` and `runpy.run_module` don't set the same __name__ -- specifically `runpy.run_module`, when given a non-package, defaults to setting __name__ to `mod_name`. So, given package/foo.py, with the "common" `if __name__ == "__main__":` check at the bottom, `python -m package.foo` successfully executes, but `runpy.run_module("package.foo")` exits silently, unless explicitly passed `runpy.run_module("package.foo", run_name="__main__"). [n.b. pep517.{build,check} is a specific example of such a module that advertises itself as wanting to be executed via `python -m`] issue16737 seems related but not exactly the same from what I can tell. ---------- messages: 350387 nosy: Julian priority: normal severity: normal status: open title: python -m and runpy.run_module set different __name__ by default _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 14:05:26 2019 From: report at bugs.python.org (Victor Milovanov) Date: Sat, 24 Aug 2019 18:05:26 +0000 Subject: [issue35235] Access violation on alloc in Windows x86-64 python, pymalloc_alloc In-Reply-To: <1542131178.89.0.788709270274.issue35235@psf.upfronthosting.co.za> Message-ID: <1566669926.88.0.969751086865.issue35235@roundup.psfhosted.org> Victor Milovanov added the comment: A bit more information: pool->freeblock for the broken pool looks like this: 0xXYZ????? while pool itself looks like this: 0x??XYZ000 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 14:14:24 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 18:14:24 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566670464.25.0.963720745615.issue37798@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset d5a66bc56f68d0f7cc3470722a31d7f731754af6 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-37798: Test both Python and C versions in test_statistics.py (GH-15453) (GH-15467) https://github.com/python/cpython/commit/d5a66bc56f68d0f7cc3470722a31d7f731754af6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 14:14:59 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 18:14:59 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566670499.79.0.994997984031.issue37798@roundup.psfhosted.org> Raymond Hettinger added the comment: Thank you again. This was nice work. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 14:15:47 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 18:15:47 +0000 Subject: [issue14112] tutorial intro talks of "shallow copy" concept without explanation In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za> Message-ID: <1566670547.23.0.301461224206.issue14112@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 69ee87e99cfe0b79389cffa92d126af868baf353 by Raymond Hettinger in branch 'master': bpo-14112: Allow beginners to explore shallowness in greater depth ;-) (GH-15465) https://github.com/python/cpython/commit/69ee87e99cfe0b79389cffa92d126af868baf353 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 14:15:55 2019 From: report at bugs.python.org (miss-islington) Date: Sat, 24 Aug 2019 18:15:55 +0000 Subject: [issue14112] tutorial intro talks of "shallow copy" concept without explanation In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za> Message-ID: <1566670555.05.0.783918585206.issue14112@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15160 pull_request: https://github.com/python/cpython/pull/15469 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 14:19:14 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 18:19:14 +0000 Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used. In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za> Message-ID: <1566670753.99.0.244555314635.issue24726@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 14:33:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 18:33:06 +0000 Subject: [issue9634] Add timeout parameter to Queue.join() In-Reply-To: <1282153581.83.0.092560551276.issue9634@psf.upfronthosting.co.za> Message-ID: <1566671586.49.0.629781779777.issue9634@roundup.psfhosted.org> Raymond Hettinger added the comment: It's been 4 1/2 years since last activity. Marking as closed again due to lack of interest and due to the rarity of need. Also we know that a person can already customize join() via a subclass. ---------- resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 14:33:21 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 18:33:21 +0000 Subject: [issue14112] tutorial intro talks of "shallow copy" concept without explanation In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za> Message-ID: <1566671601.21.0.695706362818.issue14112@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset a8424940b4873791fc178a9f19a7bf1779a6cf42 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-14112: Allow beginners to explore shallowness in greater depth ;-) (GH-15465) (GH-15469) https://github.com/python/cpython/commit/a8424940b4873791fc178a9f19a7bf1779a6cf42 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 14:33:45 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 18:33:45 +0000 Subject: [issue14112] tutorial intro talks of "shallow copy" concept without explanation In-Reply-To: <1330113005.05.0.0872009811322.issue14112@psf.upfronthosting.co.za> Message-ID: <1566671625.89.0.0417699615124.issue14112@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks Terry. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 15:09:51 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 19:09:51 +0000 Subject: [issue37942] Generate correct error check for PyFloat_AsDouble Message-ID: <1566673791.31.0.298012277207.issue37942@roundup.psfhosted.org> New submission from Raymond Hettinger : The API for PyFloat_AsDouble() returns -1.0 to indicate an error. PyErr_Occurred() should only be called if there is a -1.0 return code. This is the normal practice for those calls and it is a bit faster because it avoids unnecessary external call. ---------- components: Argument Clinic messages: 350395 nosy: larry, rhettinger priority: normal severity: normal status: open title: Generate correct error check for PyFloat_AsDouble type: behavior versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 15:13:30 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 19:13:30 +0000 Subject: [issue37942] Generate correct error check for PyFloat_AsDouble In-Reply-To: <1566673791.31.0.298012277207.issue37942@roundup.psfhosted.org> Message-ID: <1566674010.14.0.768409814257.issue37942@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +15161 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15470 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 15:16:12 2019 From: report at bugs.python.org (Batuhan) Date: Sat, 24 Aug 2019 19:16:12 +0000 Subject: [issue26093] __qualname__ different when calling generator object w/ functions.partial In-Reply-To: <1452638028.1.0.595104762218.issue26093@psf.upfronthosting.co.za> Message-ID: <1566674172.04.0.707430012307.issue26093@roundup.psfhosted.org> Batuhan added the comment: This bug is fixed in 3.9 (probably in 3.8 too) ---------- nosy: +BTaskaya _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 15:18:05 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 19:18:05 +0000 Subject: [issue37942] Generate correct error check for PyFloat_AsDouble In-Reply-To: <1566673791.31.0.298012277207.issue37942@roundup.psfhosted.org> Message-ID: <1566674285.44.0.717219773652.issue37942@roundup.psfhosted.org> Raymond Hettinger added the comment: Note, the argument clinic is already generating code like this for return values in "class double_return_converter". For example, _return_value = _statistics__normal_dist_inv_cdf_impl(module, p, mu, sigma); if ((_return_value == -1.0) && PyErr_Occurred()) { goto exit; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 16:07:09 2019 From: report at bugs.python.org (Kyle Stanley) Date: Sat, 24 Aug 2019 20:07:09 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1566677229.17.0.764981604224.issue37812@roundup.psfhosted.org> Kyle Stanley added the comment: > May I suggest directing your efforts towards fixing known bugs or implementing requested features. It isn't our goal to create more work for one another There frequently is value in improving code readability, as it can improve maintainability in the long term, but I definitely understand your point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 16:17:48 2019 From: report at bugs.python.org (Kyle Stanley) Date: Sat, 24 Aug 2019 20:17:48 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566677868.25.0.389506395423.issue34679@roundup.psfhosted.org> Kyle Stanley added the comment: > Skipping this call for non-main thread in proactor implementation makes sense. How do we identify whether or not set_wakeup_fd() is being called from a non-main thread? ---------- nosy: +aeros167 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 16:50:08 2019 From: report at bugs.python.org (Tal Einat) Date: Sat, 24 Aug 2019 20:50:08 +0000 Subject: [issue37903] IDLE Shell sidebar. In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org> Message-ID: <1566679808.6.0.157375582627.issue37903@roundup.psfhosted.org> Change by Tal Einat : ---------- keywords: +patch pull_requests: +15162 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/15474 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 16:51:50 2019 From: report at bugs.python.org (Tal Einat) Date: Sat, 24 Aug 2019 20:51:50 +0000 Subject: [issue37903] IDLE Shell sidebar. In-Reply-To: <1566370033.98.0.615651298891.issue37903@roundup.psfhosted.org> Message-ID: <1566679910.46.0.741452675075.issue37903@roundup.psfhosted.org> Tal Einat added the comment: See PR GH-15474 with an implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 17:27:59 2019 From: report at bugs.python.org (Kyle Stanley) Date: Sat, 24 Aug 2019 21:27:59 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566682078.99.0.781993098913.issue34679@roundup.psfhosted.org> Kyle Stanley added the comment: > How do we identify whether or not set_wakeup_fd() is being called from a non-main thread? Never mind, I think I found the answer to my own question and tested a patch locally, I'll open a PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 17:40:45 2019 From: report at bugs.python.org (Kyle Stanley) Date: Sat, 24 Aug 2019 21:40:45 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566682845.03.0.0841711594672.issue34679@roundup.psfhosted.org> Change by Kyle Stanley : ---------- keywords: +patch pull_requests: +15163 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15477 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 18:22:47 2019 From: report at bugs.python.org (Kyle Stanley) Date: Sat, 24 Aug 2019 22:22:47 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566685367.26.0.000948457290092.issue34679@roundup.psfhosted.org> Change by Kyle Stanley : ---------- keywords: +needs review -patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 18:32:41 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 24 Aug 2019 22:32:41 +0000 Subject: [issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT) In-Reply-To: <1565471250.77.0.491506074373.issue37812@roundup.psfhosted.org> Message-ID: <1566685961.98.0.0179233211538.issue37812@roundup.psfhosted.org> Greg Price added the comment: > May I suggest directing your efforts towards fixing known bugs or implementing requested features. Well, I would certainly be grateful for a review on my fix to #18236. ;-) There's also a small docs bug at GH-15301. I do think there's significant value in making code easier to read and less tricky. If the project continues to be successful for a long time to come, then that means the code will be read many, many more times than it's written. But one particular spot where it seems our experiences interestingly differ is: > They are a bit tedious to review and are eating up our time in the back and forth. As a reviewer I generally find it much less work to review a change when it's intended to have no effect on the code's behavior. First, because it's easier to confirm no effect than to pin down what the effects are; then because the whole set of questions about whether the effects are desirable doesn't arise. As a result I often ask contributors (to Zulip, say) to split a change into a series of small pure refactors, followed by a very focused diff for the behavior change. So that's certainly background to my sending as many PRs that don't change any behavior as PRs that do. I actually have quite a number of draft changes built up over the last few weeks. I've held back on sending them all at once, partly because I've felt I have enough open PRs and I wanted to get a better sense of how reviews go. Perhaps I'll go pick out a couple more of them that are bugfixes, features, and docs to send next. (You didn't mention docs just now, but given the care I see you take in adding to them and in revising What's New, I think we agree that work there is valuable.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 18:32:56 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sat, 24 Aug 2019 22:32:56 +0000 Subject: [issue18153] python imaplib - error 'unexpected response' In-Reply-To: <1370564442.51.0.371517794914.issue18153@psf.upfronthosting.co.za> Message-ID: <1566685976.75.0.67736264742.issue18153@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- title: python imaplib - error 'unexpected repsonse' -> python imaplib - error 'unexpected response' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 18:35:09 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sat, 24 Aug 2019 22:35:09 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566686109.03.0.886048568025.issue37798@roundup.psfhosted.org> Dong-hee Na added the comment: Thank you for the mentoring of this work. It was great experience for me! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 18:37:27 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 22:37:27 +0000 Subject: [issue19072] classmethod doesn't honour descriptor protocol of wrapped callable In-Reply-To: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za> Message-ID: <1566686247.94.0.896478388467.issue19072@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 805f8f9afea116c5d4d000570e3d02ae84502f43 by Raymond Hettinger (Berker Peksag) in branch 'master': bpo-19072: Make @classmethod support chained decorators (GH-8405) https://github.com/python/cpython/commit/805f8f9afea116c5d4d000570e3d02ae84502f43 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 18:37:58 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 24 Aug 2019 22:37:58 +0000 Subject: [issue19072] classmethod doesn't honour descriptor protocol of wrapped callable In-Reply-To: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za> Message-ID: <1566686278.67.0.933794115264.issue19072@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 18:51:03 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sat, 24 Aug 2019 22:51:03 +0000 Subject: [issue31956] Add start and stop parameters to the array.index() In-Reply-To: <1509966827.68.0.213398074469.issue31956@psf.upfronthosting.co.za> Message-ID: <1566687063.17.0.395818678013.issue31956@roundup.psfhosted.org> Joannah Nanjekye added the comment: There is a pending PR here : https://github.com/python/cpython/pull/4435 by phaqui. @phaqui do you want to finish your PR ? ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 19:03:05 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 24 Aug 2019 23:03:05 +0000 Subject: [issue37837] add internal _PyLong_FromUnsignedChar() function In-Reply-To: <1565692195.8.0.862568192553.issue37837@roundup.psfhosted.org> Message-ID: <1566687785.63.0.996496441368.issue37837@roundup.psfhosted.org> Greg Price added the comment: Hmm, I'm a bit confused because: * Your patch at GH-15251 replaces a number of calls to PyLong_FromLong with calls to the new _PyLong_FromUnsignedChar. * That function, in turn, just calls PyLong_FromSize_t. * And that function begins: PyObject * PyLong_FromSize_t(size_t ival) { PyLongObject *v; size_t t; int ndigits = 0; if (ival < PyLong_BASE) return PyLong_FromLong((long)ival); // ... * So, it seems like after your patch we still end up calling PyLong_FromLong at each of these callsites, just after a couple more indirections than before. Given the magic of compilers and of hardware branch prediction, it wouldn't at all surprise me for those indirections to not make anything slower... but if the measurements are coming out *faster*, then I feel like something else must be going on. ;-) Ohhh, I see -- I bet it's that at _PyLong_FromUnsignedChar, the compiler can see that `is_small_int(ival)` is always true, so the whole function just turns into get_small_int. Whereas when compiling a call to PyLong_FromLong from some other file (other translation unit), it can't see that and can't make the optimization. Two questions, then: * How do the measurements look under LTO? I wonder if with LTO the linker is able to make the same optimization that this change helps the compiler make. * Is there a particular reason to specifically call PyLong_FromSize_t? Seems like PyLong_FromLong is the natural default (and what we default to in the rest of the code), and it's what this ends up calling anyway. ---------- nosy: +Greg Price _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 19:04:46 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 24 Aug 2019 23:04:46 +0000 Subject: [issue37837] add internal _PyLong_FromUnsignedChar() function In-Reply-To: <1565692195.8.0.862568192553.issue37837@roundup.psfhosted.org> Message-ID: <1566687886.57.0.786805308419.issue37837@roundup.psfhosted.org> Greg Price added the comment: Oh also: * What compiler, and what compilation flags, are you using in your benchmarking? That seems relevant :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 19:06:17 2019 From: report at bugs.python.org (Jens Troeger) Date: Sat, 24 Aug 2019 23:06:17 +0000 Subject: =?utf-8?q?=5Bissue37943=5D_mimetypes=2Eguess=5Fextension=28=29_doesn?= =?utf-8?q?=E2=80=99t_get_JPG_right?= Message-ID: <1566687977.17.0.676940180845.issue37943@roundup.psfhosted.org> New submission from Jens Troeger : I think this one?s quite easy to reproduce: Python 3.7.4 (default, Jul 11 2019, 01:08:00) [Clang 10.0.1 (clang-1001.0.46.4)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import mimetypes >>> mimetypes.guess_extension("image/jpg") # Expected ".jpg" >>> mimetypes.guess_extension("image/jpeg") # Expected ".jpg" '.jpe' According to MDN https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types only "image/jpeg" is a valid MIME type; however, I?ve seen quite a bit of "image/jpg" out in the wild and I think that ought to be accounted for too. Before I look into submitting a PR I wanted to confirm that this is an issue that ought to be fixed. I think it is. ---------- components: Library (Lib) messages: 350408 nosy: _savage priority: normal severity: normal status: open title: mimetypes.guess_extension() doesn?t get JPG right type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 19:08:14 2019 From: report at bugs.python.org (Jens Troeger) Date: Sat, 24 Aug 2019 23:08:14 +0000 Subject: =?utf-8?q?=5Bissue37943=5D_mimetypes=2Eguess=5Fextension=28=29_doesn?= =?utf-8?q?=E2=80=99t_get_JPG_right?= In-Reply-To: <1566687977.17.0.676940180845.issue37943@roundup.psfhosted.org> Message-ID: <1566688094.67.0.373620778961.issue37943@roundup.psfhosted.org> Jens Troeger added the comment: Oops, forgot? >>> mimetypes.guess_extension("image/jpeg") # Expected ".jpg" or ".jpeg" as per referenced MDN. I personally would go with ".jpg" because that's the more common file name extension. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 19:19:32 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sat, 24 Aug 2019 23:19:32 +0000 Subject: [issue15542] Documentation incorrectly suggests __init__ called after direct __new__ call In-Reply-To: <1343946223.73.0.562621858875.issue15542@psf.upfronthosting.co.za> Message-ID: <1566688772.95.0.804607780477.issue15542@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- keywords: +patch pull_requests: +15164 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15478 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 19:22:15 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sat, 24 Aug 2019 23:22:15 +0000 Subject: [issue15542] Documentation incorrectly suggests __init__ called after direct __new__ call In-Reply-To: <1343946223.73.0.562621858875.issue15542@psf.upfronthosting.co.za> Message-ID: <1566688935.02.0.452691432509.issue15542@roundup.psfhosted.org> Joannah Nanjekye added the comment: Since this has taken long on the tracker, I just opened a PR with proposed changes from Aaron. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 19:22:38 2019 From: report at bugs.python.org (Greg Price) Date: Sat, 24 Aug 2019 23:22:38 +0000 Subject: [issue37837] add internal _PyLong_FromUnsignedChar() function In-Reply-To: <1565692195.8.0.862568192553.issue37837@roundup.psfhosted.org> Message-ID: <1566688958.43.0.896087473315.issue37837@roundup.psfhosted.org> Greg Price added the comment: > Is there a particular reason to specifically call PyLong_FromSize_t? Seems like PyLong_FromLong is the natural default (and what we default to in the rest of the code), and it's what this ends up calling anyway. Ah I see, the patch is meant to go on top of GH-15192, which makes PyLong_FromSize_t apply the small-int optimization itself. As I just suggested on GH-15192, I'd like to see that PR apply the small-int optimization in the more broadly-used PyLong_FromUnsignedLong... and then I think the natural thing for this new function to do is to call that. Still quite curious how LTO does, and also curious what compiler and flags you're using in benchmarks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 19:46:54 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Sat, 24 Aug 2019 23:46:54 +0000 Subject: [issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0 In-Reply-To: <1351070553.1.0.217274613803.issue16308@psf.upfronthosting.co.za> Message-ID: <1566690414.82.0.440441274825.issue16308@roundup.psfhosted.org> Ashwin Ramaswami added the comment: What's the status of this? Was paul.j3's patch ever reviewed? ---------- nosy: +epicfaace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 19:47:04 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Sat, 24 Aug 2019 23:47:04 +0000 Subject: [issue9253] argparse: optional subparsers In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za> Message-ID: <1566690424.44.0.983873036752.issue9253@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- nosy: +epicfaace _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 20:14:20 2019 From: report at bugs.python.org (Anthony Sottile) Date: Sun, 25 Aug 2019 00:14:20 +0000 Subject: [issue37636] Deprecate slicing and ordering operations on sys.version In-Reply-To: <1563626755.13.0.11799518747.issue37636@roundup.psfhosted.org> Message-ID: <1566692060.41.0.138808115806.issue37636@roundup.psfhosted.org> Anthony Sottile added the comment: I threw together a flake8 plugin which checks for these usage patterns: https://github.com/asottile/flake8-2020 | Code | Description | |--------|-------------------------------------------------| | YTT101 | `sys.version[:...]` referenced (python3.10) | | YTT102 | `sys.version[2]` referenced (python3.10) | | YTT201 | `sys.version_info[0] == 3` referenced (python4) | | YTT202 | `six.PY3` referenced (python4) | | YTT301 | `sys.version[0]` referenced (python10) | ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 20:33:01 2019 From: report at bugs.python.org (Greg Price) Date: Sun, 25 Aug 2019 00:33:01 +0000 Subject: [issue18236] str.isspace should use the Unicode White_Space property In-Reply-To: <1371431190.78.0.117337167573.issue18236@psf.upfronthosting.co.za> Message-ID: <1566693181.09.0.890676150292.issue18236@roundup.psfhosted.org> Greg Price added the comment: > I've gone and made a patch for this change Update: * The preparatory changes in #37760 are now almost all merged; GH-15265 is the one piece remaining, and I'd be grateful for a review. It's a generally straightforward and boring change that converts the main data structures of makeunicodedata.py from using length-18 tuples as records to using a dataclass, which I think makes subsequent changes that add features to that script much easier both to write and to review. * I have a slightly updated version of the fix itself, which differs mainly by adding a test: https://github.com/gnprice/cpython/commit/9b3bf6739 Comments welcome there too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 20:50:08 2019 From: report at bugs.python.org (paul j3) Date: Sun, 25 Aug 2019 00:50:08 +0000 Subject: [issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0 In-Reply-To: <1351070553.1.0.217274613803.issue16308@psf.upfronthosting.co.za> Message-ID: <1566694208.95.0.731764671762.issue16308@roundup.psfhosted.org> paul j3 added the comment: https://bugs.python.org/issue26510 https://bugs.python.org/issue33109 There was some flip/flop over whether required should be true by default or not - the current behavior is False, (the 3.3.0) The lasting change since this issue in 2012 is that `add_subparsers` now takes the 'required' parameter. And this is documented. To avoid the problem raising in this issue, the subparsers should be defined with: p1 = parser.add_subparsers(required=True, dest='cmd') The 'dest' parameter is documented, but that fact that it is needed with required=True is not. Without it you can get an error when missing-argument is being formatted. Without it the error formatter doesn't know what to call this argument. I've mentioned this in one or more issues. See my SO answer for discussion on this: https://stackoverflow.com/questions/23349349/argparse-with-required-subparser/23354355#23354355 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 20:50:57 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 25 Aug 2019 00:50:57 +0000 Subject: [issue23061] Update pep8 to specify explicitly 'module level' imports at top of file In-Reply-To: <1418703864.09.0.281927050653.issue23061@psf.upfronthosting.co.za> Message-ID: <1566694257.01.0.328455940165.issue23061@roundup.psfhosted.org> Joannah Nanjekye added the comment: Since this is a PEP related issue, it should be moved to the PEP Github repository here : https://github.com/python/peps . If it still exists. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 21:00:21 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 25 Aug 2019 01:00:21 +0000 Subject: [issue13341] Incorrect documentation for "u" PyArg_Parse format unit In-Reply-To: <1320412814.48.0.657162308895.issue13341@psf.upfronthosting.co.za> Message-ID: <1566694821.2.0.137968728482.issue13341@roundup.psfhosted.org> Joannah Nanjekye added the comment: This is has taken years but am curious, are we allowed to patch Python 2 given its EOL is almost due. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 21:53:40 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 25 Aug 2019 01:53:40 +0000 Subject: [issue20806] os.times document points to wrong section of non-Linux manual In-Reply-To: <1393590805.13.0.860460942185.issue20806@psf.upfronthosting.co.za> Message-ID: <1566698020.28.0.122596928602.issue20806@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- keywords: +patch pull_requests: +15165 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15479 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 21:57:05 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 25 Aug 2019 01:57:05 +0000 Subject: [issue20806] os.times document points to wrong section of non-Linux manual In-Reply-To: <1393590805.13.0.860460942185.issue20806@psf.upfronthosting.co.za> Message-ID: <1566698225.59.0.0905885978296.issue20806@roundup.psfhosted.org> Joannah Nanjekye added the comment: I opened a PR for this. @david please review. ---------- nosy: +nanjekyejoannah stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 22:10:42 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 02:10:42 +0000 Subject: [issue37942] Generate correct error check for PyFloat_AsDouble In-Reply-To: <1566673791.31.0.298012277207.issue37942@roundup.psfhosted.org> Message-ID: <1566699042.32.0.0461088751371.issue37942@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset aef9ad82f7f667cd001a7112d3bc636e918626f7 by Raymond Hettinger in branch 'master': bpo-37942: Improve argument clinic float converter (GH-15470) https://github.com/python/cpython/commit/aef9ad82f7f667cd001a7112d3bc636e918626f7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 22:21:52 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 25 Aug 2019 02:21:52 +0000 Subject: [issue23061] Update pep8 to specify explicitly 'module level' imports at top of file In-Reply-To: <1418703864.09.0.281927050653.issue23061@psf.upfronthosting.co.za> Message-ID: <1566699712.46.0.221204553363.issue23061@roundup.psfhosted.org> Terry J. Reedy added the comment: At least some idlelib imports are delayed to avoid circular import errors, as described by Nick. The patch adds 'Module level' before 'imports'. Pro: techinically correct as only module level imports can be put at the top. Com: might be seen as giving too much license to putting imports elsewhere. Raymond, what do you think? If you are not 'pro' enough to make the change, I think we should close. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 22:25:46 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 02:25:46 +0000 Subject: [issue37942] Generate correct error check for PyFloat_AsDouble In-Reply-To: <1566673791.31.0.298012277207.issue37942@roundup.psfhosted.org> Message-ID: <1566699946.31.0.69875308057.issue37942@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +15166 pull_request: https://github.com/python/cpython/pull/15480 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 22:39:39 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 02:39:39 +0000 Subject: [issue23061] Update pep8 to specify explicitly 'module level' imports at top of file In-Reply-To: <1418703864.09.0.281927050653.issue23061@psf.upfronthosting.co.za> Message-ID: <1566700779.25.0.822189872936.issue23061@roundup.psfhosted.org> Raymond Hettinger added the comment: I concur that this should be closed. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 22:45:15 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 02:45:15 +0000 Subject: [issue37942] Generate correct error check for PyFloat_AsDouble In-Reply-To: <1566673791.31.0.298012277207.issue37942@roundup.psfhosted.org> Message-ID: <1566701115.25.0.46722614949.issue37942@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 21161d73d979012ec3b7247261178b3aa1555486 by Raymond Hettinger in branch '3.8': [3.8] bpo-37942: Improve argument clinic float converter (GH-15470) (GH-15480) https://github.com/python/cpython/commit/21161d73d979012ec3b7247261178b3aa1555486 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 22:45:37 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 02:45:37 +0000 Subject: [issue37942] Generate correct error check for PyFloat_AsDouble In-Reply-To: <1566673791.31.0.298012277207.issue37942@roundup.psfhosted.org> Message-ID: <1566701137.33.0.818940728606.issue37942@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 23:14:11 2019 From: report at bugs.python.org (hongweipeng) Date: Sun, 25 Aug 2019 03:14:11 +0000 Subject: [issue37914] class timedelta, support the method hours and minutes in field accessors In-Reply-To: <1566470893.59.0.211009594568.issue37914@roundup.psfhosted.org> Message-ID: <1566702851.18.0.309839738271.issue37914@roundup.psfhosted.org> Change by hongweipeng : ---------- keywords: +patch pull_requests: +15167 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15481 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 23:16:59 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 03:16:59 +0000 Subject: [issue19419] Use abc.ABC in the collections ABC In-Reply-To: <1382907896.33.0.659909240184.issue19419@psf.upfronthosting.co.za> Message-ID: <1566703019.59.0.134890923487.issue19419@roundup.psfhosted.org> Raymond Hettinger added the comment: This was done a long time ago. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Aug 24 23:20:23 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 03:20:23 +0000 Subject: [issue14619] Enhanced variable substitution for databases In-Reply-To: <1334812495.3.0.737876206598.issue14619@psf.upfronthosting.co.za> Message-ID: <1566703223.51.0.306221340531.issue14619@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 00:42:15 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 04:42:15 +0000 Subject: [issue15542] Documentation incorrectly suggests __init__ called after direct __new__ call In-Reply-To: <1343946223.73.0.562621858875.issue15542@psf.upfronthosting.co.za> Message-ID: <1566708135.27.0.414976642812.issue15542@roundup.psfhosted.org> Raymond Hettinger added the comment: FWIW, the underlying code for this in Objects/typeobject.c::type_new(). ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 00:49:21 2019 From: report at bugs.python.org (Pradyun Gedam) Date: Sun, 25 Aug 2019 04:49:21 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566708561.88.0.946958425286.issue37664@roundup.psfhosted.org> Change by Pradyun Gedam : ---------- pull_requests: +15168 pull_request: https://github.com/python/cpython/pull/15482 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 00:55:55 2019 From: report at bugs.python.org (Pradyun Gedam) Date: Sun, 25 Aug 2019 04:55:55 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566708955.62.0.951471532793.issue37664@roundup.psfhosted.org> Change by Pradyun Gedam : ---------- pull_requests: +15169 pull_request: https://github.com/python/cpython/pull/15483 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 00:57:15 2019 From: report at bugs.python.org (Pradyun Gedam) Date: Sun, 25 Aug 2019 04:57:15 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566709035.79.0.103668110445.issue37664@roundup.psfhosted.org> Pradyun Gedam added the comment: Made the release and the PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 01:20:44 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Sun, 25 Aug 2019 05:20:44 +0000 Subject: [issue37837] add internal _PyLong_FromUnsignedChar() function In-Reply-To: <1565692195.8.0.862568192553.issue37837@roundup.psfhosted.org> Message-ID: <1566710444.66.0.283014336649.issue37837@roundup.psfhosted.org> Sergey Fedoseev added the comment: $ gcc -v 2>&1 | grep 'gcc version' gcc version 8.3.0 (Debian 8.3.0-19) using ./configure --enable-optimizations --with-lto $ python -m perf timeit -s "from collections import deque; consume = deque(maxlen=0).extend; b = bytes(2**20)" "consume(b)" --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 6.71 ms +- 0.09 ms /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 6.71 ms +- 0.08 ms Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 6.71 ms +- 0.09 ms -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 6.71 ms +- 0.08 ms: 1.00x slower (+0%) using ./configure --enable-optimizations $ python -m perf timeit -s "from collections import deque; consume = deque(maxlen=0).extend; b = bytes(2**20)" "consume(b)" --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 6.73 ms +- 0.17 ms /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 4.28 ms +- 0.01 ms Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 6.73 ms +- 0.17 ms -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 4.28 ms +- 0.01 ms: 1.57x faster (-36%) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 01:53:01 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 25 Aug 2019 05:53:01 +0000 Subject: [issue37929] IDLE: OK sometimes fails to close configdialog In-Reply-To: <1566566864.85.0.308464800085.issue37929@roundup.psfhosted.org> Message-ID: <1566712381.96.0.222180393803.issue37929@roundup.psfhosted.org> Tal Einat added the comment: New changeset d4b4c00b57d24f6ee2cf3a96213406bb09953df3 by Tal Einat in branch 'master': bpo-37929: IDLE: avoid Squeezer-related config dialog crashes (GH-15452) https://github.com/python/cpython/commit/d4b4c00b57d24f6ee2cf3a96213406bb09953df3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 01:53:11 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 25 Aug 2019 05:53:11 +0000 Subject: [issue37929] IDLE: OK sometimes fails to close configdialog In-Reply-To: <1566566864.85.0.308464800085.issue37929@roundup.psfhosted.org> Message-ID: <1566712391.62.0.16657931325.issue37929@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15171 pull_request: https://github.com/python/cpython/pull/15484 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 01:53:47 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 25 Aug 2019 05:53:47 +0000 Subject: [issue37929] IDLE: OK sometimes fails to close configdialog In-Reply-To: <1566566864.85.0.308464800085.issue37929@roundup.psfhosted.org> Message-ID: <1566712427.76.0.903052182866.issue37929@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15172 pull_request: https://github.com/python/cpython/pull/15485 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 02:00:37 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 25 Aug 2019 06:00:37 +0000 Subject: [issue35855] IDLE squeezer: improve unsqueezing and autosqueeze default In-Reply-To: <1548818070.19.0.784051079348.issue35855@roundup.psfhosted.org> Message-ID: <1566712837.56.0.596957191219.issue35855@roundup.psfhosted.org> Tal Einat added the comment: See issue #37827 regarding handling of progress output, as written by tensorflow.keras for example. ---------- versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 02:17:23 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 25 Aug 2019 06:17:23 +0000 Subject: [issue37929] IDLE: OK sometimes fails to close configdialog In-Reply-To: <1566566864.85.0.308464800085.issue37929@roundup.psfhosted.org> Message-ID: <1566713843.7.0.157836737845.issue37929@roundup.psfhosted.org> miss-islington added the comment: New changeset f2b468dd6d0bdbe2e87c0ca7515800a115e95e54 by Miss Islington (bot) in branch '3.7': bpo-37929: IDLE: avoid Squeezer-related config dialog crashes (GH-15452) https://github.com/python/cpython/commit/f2b468dd6d0bdbe2e87c0ca7515800a115e95e54 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 02:18:04 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 25 Aug 2019 06:18:04 +0000 Subject: [issue37929] IDLE: OK sometimes fails to close configdialog In-Reply-To: <1566566864.85.0.308464800085.issue37929@roundup.psfhosted.org> Message-ID: <1566713884.55.0.676982754746.issue37929@roundup.psfhosted.org> miss-islington added the comment: New changeset e266d062e017b122b9741db2bd5fb99742378623 by Miss Islington (bot) in branch '3.8': bpo-37929: IDLE: avoid Squeezer-related config dialog crashes (GH-15452) https://github.com/python/cpython/commit/e266d062e017b122b9741db2bd5fb99742378623 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 02:21:56 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 06:21:56 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566714116.19.0.39066650446.issue36205@roundup.psfhosted.org> Raymond Hettinger added the comment: Something in the release build process is triggering this behavior (perhaps PGO). I observe the bug on the python.org official 3.8b3 release, official 3.7 release, but not in the official 3.6 release: $ python3.8 ~/time_compare.py Python ('v3.8.0b3:4336222407', 'Jul 29 2019 09:46:03') Clang 6.0 (clang-600.0.57) CPU Time: 14.632004 Wall Clock: 7.318585415 Distance: 750 $ python3.7 ~/time_compare.py Python ('v3.7.4:e09359112e', 'Jul 8 2019 14:54:52') Clang 6.0 (clang-600.0.57) CPU Time: 16.405296 Wall Clock: 8.208222215000001 Distance: 750 $ python3.6 ~/time_compare.py Python ('v3.6.8:3c6b436a57', 'Dec 24 2018 02:04:31') GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57) CPU Time: 8.645299 Wall Clock: 8.647321333999571 Distance: 7 However, when I do my own fresh build for 3.8b3, the problem disappears: $ py ~/time_compare.py Python ('tags/v3.8.0b3:4336222407', 'Aug 24 2019 23:08:57') Clang 10.0.1 (clang-1001.0.46.4) CPU Time: 7.446087 Wall Clock: 7.447327639 Distance: 750 I build with the following process: make distclean ./configure --with-openssl=$(brew --prefix openssl) make ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 02:25:32 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 25 Aug 2019 06:25:32 +0000 Subject: [issue37929] IDLE: OK sometimes fails to close configdialog In-Reply-To: <1566566864.85.0.308464800085.issue37929@roundup.psfhosted.org> Message-ID: <1566714332.38.0.0944601836315.issue37929@roundup.psfhosted.org> Tal Einat added the comment: Fixed. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 02:25:36 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 06:25:36 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566714336.48.0.705056393613.issue36205@roundup.psfhosted.org> Raymond Hettinger added the comment: If it matters, I'm on Mojave 10.14.6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 02:32:35 2019 From: report at bugs.python.org (Greg Price) Date: Sun, 25 Aug 2019 06:32:35 +0000 Subject: [issue37837] add internal _PyLong_FromUnsignedChar() function In-Reply-To: <1565692195.8.0.862568192553.issue37837@roundup.psfhosted.org> Message-ID: <1566714755.54.0.372843929228.issue37837@roundup.psfhosted.org> Greg Price added the comment: Very interesting, thanks! It looks like with LTO enabled, this optimization has no effect at all. This change adds significant complexity, and it seems like the hoped-for payoff is entirely in terms of performance on rather narrowly-focused microbenchmarks. In general I think that sets the bar rather high for making sure the performance gains are meaningful enough to justify the increase in complexity in the code. In particular, I expect most anyone running Python and concerned with performance to be using LTO. (It's standard in distro builds of Python, so that covers probably most users already.) That means if the optimization doesn't do anything in the presence of LTO, it doesn't really count. ;-) --- Now, I am surprised at the specifics of the result! I expected that LTO would probably pick up the equivalent optimization on its own, so that this change didn't have an effect. Instead, it looks like with LTO, this microbenchmark performs the same as it does without LTO *before* this change. That suggests that LTO may instead be blocking this optimization. In that case, there may still be an opportunity: if you can work out why the change doesn't help under LTO, maybe you can find a way to make this optimization happen under LTO after all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 03:00:53 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 25 Aug 2019 07:00:53 +0000 Subject: [issue23423] XPath Support in ElementTree doc omission In-Reply-To: <1423510779.4.0.551912157105.issue23423@psf.upfronthosting.co.za> Message-ID: <1566716453.74.0.206060805893.issue23423@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 03:45:59 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 25 Aug 2019 07:45:59 +0000 Subject: [issue23423] XPath Support in ElementTree doc omission In-Reply-To: <1423510779.4.0.551912157105.issue23423@psf.upfronthosting.co.za> Message-ID: <1566719159.15.0.718334381997.issue23423@roundup.psfhosted.org> Stefan Behnel added the comment: Already fixed in later versions of the documentation: https://docs.python.org/3/library/xml.etree.elementtree.html#supported-xpath-syntax Note that Py3.4 is no longer maintained. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 03:50:39 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 07:50:39 +0000 Subject: [issue37905] Improve docs for NormalDist In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566719439.34.0.223978584234.issue37905@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +15173 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15486 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 03:57:30 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 07:57:30 +0000 Subject: [issue37905] Improve docs for NormalDist In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566719850.54.0.218558447279.issue37905@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 8371799e300475c8f9f967e900816218d3500e5d by Raymond Hettinger in branch 'master': bpo-37905: Improve docs for NormalDist (GH-15486) https://github.com/python/cpython/commit/8371799e300475c8f9f967e900816218d3500e5d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 03:57:38 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 25 Aug 2019 07:57:38 +0000 Subject: [issue37905] Improve docs for NormalDist In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566719858.57.0.0697357552889.issue37905@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15174 pull_request: https://github.com/python/cpython/pull/15487 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 04:04:28 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 08:04:28 +0000 Subject: [issue37905] Improve docs for NormalDist In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566720268.16.0.387814919862.issue37905@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 970548c00b366dcb8eb0c2bec0ffcab30ba03aee by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-37905: Improve docs for NormalDist (GH-15486) (GH-15487) https://github.com/python/cpython/commit/970548c00b366dcb8eb0c2bec0ffcab30ba03aee ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 04:06:03 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 08:06:03 +0000 Subject: [issue37905] Improve docs for NormalDist In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566720363.17.0.571316893273.issue37905@roundup.psfhosted.org> Raymond Hettinger added the comment: * Removed external links in overlap() docs * Removed "same heights" example * Chose more stable parameters for the Monte Carlo model * Made the example reproducible by recording a seed value ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 04:06:22 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 25 Aug 2019 08:06:22 +0000 Subject: [issue37940] Add xml.tool to pretty print XML like json.tool In-Reply-To: <1566658533.41.0.722111821042.issue37940@roundup.psfhosted.org> Message-ID: <1566720382.69.0.0923645107348.issue37940@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Thanks Stefan for the link. XPath support sounds cool to me given that there is already support in stdlib. It could help with filtering using xml.tool itself instead of passing the output to another command to filter. My initial approach was to take it from command line --xpath argument and apply it to root node to pretty print the elements that match the XPath query. I have pushed the xpath changes also to https://github.com/tirkarthi/cpython/tree/bpo14465-xml-tool. I will try to add docstrings with xpath examples and tests to raise a PR for this. # Sample XML $ python -m xml.tool /tmp/person.xml Idly Dosa # Select person with name as Kate $ python -m xml.tool --xpath './person[@name="Kate"]' /tmp/person.xml Idly # Get all unavailable breakfast items python -m xml.tool --xpath './/breakfast[@available="false"]' /tmp/person.xml Dosa It could also mask the traceback to return error when the XPath is invalid and raises exception. # Error messages $ python -m xml.tool --xpath './person/[breakfast='Dosa']' /tmp/person.xml invalid predicate $ python -m xml.tool --xpath './/[breakfast=Dosa]' /tmp/person.xml invalid descendant ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 04:42:20 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 25 Aug 2019 08:42:20 +0000 Subject: [issue37940] Add xml.tool to pretty print XML like json.tool In-Reply-To: <1566658533.41.0.722111821042.issue37940@roundup.psfhosted.org> Message-ID: <1566722540.49.0.314743381843.issue37940@roundup.psfhosted.org> Raymond Hettinger added the comment: I don't think this should be done: * Guido didn't want Python to grow into a collection of command-line tools * Browsers like Chrome already provide XML viewers * If you pretty print JSON, you don't change its meaning, but for XML, it adds "text" and "tail" at non-leaf nodes. And if leaf text is indented and/or line-wrapped, that also changes the stored values. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 04:45:21 2019 From: report at bugs.python.org (Lorenz Mende) Date: Sun, 25 Aug 2019 08:45:21 +0000 Subject: [issue36670] regrtest: win_utils decodes typeperf output from the wrong encoding (test suite broken due to cpu usage feature on win 10/ german) In-Reply-To: <1555689157.38.0.435665423105.issue36670@roundup.psfhosted.org> Message-ID: <1566722721.06.0.0832473165769.issue36670@roundup.psfhosted.org> Change by Lorenz Mende : ---------- keywords: +patch pull_requests: +15175 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15488 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 05:31:37 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 Aug 2019 09:31:37 +0000 Subject: [issue20806] os.times document points to wrong section of non-Linux manual In-Reply-To: <1393590805.13.0.860460942185.issue20806@psf.upfronthosting.co.za> Message-ID: <1566725497.46.0.245992223311.issue20806@roundup.psfhosted.org> Serhiy Storchaka added the comment: Section 3p is OS specific (Debian and derivatives). `man 3 times` works as well. But the manpages-posix-dev is not installed by default, so changing this will add a regression on Linux. I thank that it would be better to add both references, times(2) and times(3). And we can also add a link to MSDN. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 05:41:06 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 Aug 2019 09:41:06 +0000 Subject: [issue37942] Generate correct error check for PyFloat_AsDouble In-Reply-To: <1566673791.31.0.298012277207.issue37942@roundup.psfhosted.org> Message-ID: <1566726066.93.0.880079653427.issue37942@roundup.psfhosted.org> Serhiy Storchaka added the comment: How large is benefit from special casing exact floats? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 05:44:12 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 Aug 2019 09:44:12 +0000 Subject: [issue34880] About the "assert" bytecode In-Reply-To: <1538549910.96.0.545547206417.issue34880@psf.upfronthosting.co.za> Message-ID: <1566726252.51.0.284534356063.issue34880@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset ce6a070414ed1e1374d1e6212bfbff61b6d5d755 by Serhiy Storchaka (Zackery Spytz) in branch 'master': bpo-34880: Add the LOAD_ASSERTION_ERROR opcode. (GH-15073) https://github.com/python/cpython/commit/ce6a070414ed1e1374d1e6212bfbff61b6d5d755 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 05:52:41 2019 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 25 Aug 2019 09:52:41 +0000 Subject: [issue37940] Add xml.tool to pretty print XML like json.tool In-Reply-To: <1566658533.41.0.722111821042.issue37940@roundup.psfhosted.org> Message-ID: <1566726761.98.0.446791997082.issue37940@roundup.psfhosted.org> Stefan Behnel added the comment: I agree that formatting is not a use case by itself. I like the idea of XPath grepping, though, especially *without* pretty printing, i.e. one result per line. I admit that there is no strong reason for adding such a command line tool to the stdlib, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 05:58:32 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Sun, 25 Aug 2019 09:58:32 +0000 Subject: [issue37802] micro-optimization of PyLong_FromSize_t() In-Reply-To: <1565357260.71.0.37857302813.issue37802@roundup.psfhosted.org> Message-ID: <1566727112.42.0.781757714651.issue37802@roundup.psfhosted.org> Sergey Fedoseev added the comment: Previous benchmarks results were obtained with non-LTO build. Here are results for LTO build: $ python -m perf timeit -s "from itertools import repeat; _len = repeat(None, 0).__length_hint__" "_len()" --compare-to=../cpython-master/venv/bin/python --duplicate=1000 /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 14.9 ns +- 0.2 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 13.1 ns +- 0.5 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 14.9 ns +- 0.2 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 13.1 ns +- 0.5 ns: 1.13x faster (-12%) $ python -m perf timeit -s "from itertools import repeat; _len = repeat(None, 2**10).__length_hint__" "_len()" --compare-to=../cpython-master/venv/bin/python --duplicate=1000 /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 22.1 ns +- 0.1 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 20.9 ns +- 0.4 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 22.1 ns +- 0.1 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 20.9 ns +- 0.4 ns: 1.05x faster (-5%) $ python -m perf timeit -s "from itertools import repeat; _len = repeat(None, 2**30).__length_hint__" "_len()" --compare-to=../cpython-master/venv/bin/python --duplicate=1000 /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 23.3 ns +- 0.0 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 21.6 ns +- 0.1 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 23.3 ns +- 0.0 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 21.6 ns +- 0.1 ns: 1.08x faster (-8%) $ python -m perf timeit -s "from itertools import repeat; _len = repeat(None, 2**60).__length_hint__" "_len()" --compare-to=../cpython-master/venv/bin/python --duplicate=1000 /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 24.4 ns +- 0.1 ns /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 22.7 ns +- 0.1 ns Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 24.4 ns +- 0.1 ns -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 22.7 ns +- 0.1 ns: 1.08x faster (-7%) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 06:01:51 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sun, 25 Aug 2019 10:01:51 +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: <1566727311.7.0.0702488732871.issue25026@roundup.psfhosted.org> Dong-hee Na added the comment: Can I take a look at this issue? Is there anything should I care about except update clinic? Thanks! ---------- nosy: +corona10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 06:32:19 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 Aug 2019 10:32:19 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1566729139.61.0.610834889349.issue2506@roundup.psfhosted.org> Serhiy Storchaka added the comment: There are different optimizations on different levels (AST, bytecode generation, peepholer), would be nice to control them separately. This means that we should pass a bitset to the compiler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 06:54:03 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sun, 25 Aug 2019 10:54:03 +0000 Subject: [issue37805] json.dump(..., skipkeys=True) has no unit tests In-Reply-To: <1565387683.62.0.51432990737.issue37805@roundup.psfhosted.org> Message-ID: <1566730443.69.0.490141106041.issue37805@roundup.psfhosted.org> Change by Dong-hee Na : ---------- keywords: +patch pull_requests: +15176 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15489 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 07:04:53 2019 From: report at bugs.python.org (Tal Einat) Date: Sun, 25 Aug 2019 11:04:53 +0000 Subject: [issue31706] urlencode should accept generator as values for mappings when doseq=True In-Reply-To: <1507234372.12.0.213398074469.issue31706@psf.upfronthosting.co.za> Message-ID: <1566731093.94.0.00463267529164.issue31706@roundup.psfhosted.org> Tal Einat added the comment: IMO the benefit here is very small and not worth the added complexity (implementation + tests + docs + maintenance). ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 07:10:43 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sun, 25 Aug 2019 11:10:43 +0000 Subject: [issue37805] json.dump(..., skipkeys=True) has no unit tests In-Reply-To: <1565387683.62.0.51432990737.issue37805@roundup.psfhosted.org> Message-ID: <1566731443.44.0.0592682568592.issue37805@roundup.psfhosted.org> Change by Dong-hee Na : ---------- nosy: +corona10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 07:17:35 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 25 Aug 2019 11:17:35 +0000 Subject: [issue20806] os.times document points to wrong section of non-Linux manual In-Reply-To: <1393590805.13.0.860460942185.issue20806@psf.upfronthosting.co.za> Message-ID: <1566731855.93.0.193962737852.issue20806@roundup.psfhosted.org> Joannah Nanjekye added the comment: Serhiy, This sounds good. I will update the PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 08:00:49 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 Aug 2019 12:00:49 +0000 Subject: [issue36917] ast.NodeVisitor no longer calls visit_Str In-Reply-To: <1557843682.58.0.0807679622364.issue36917@roundup.psfhosted.org> Message-ID: <1566734449.81.0.136398070653.issue36917@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +15177 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15490 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 08:51:46 2019 From: report at bugs.python.org (Elinaldo Monteiro) Date: Sun, 25 Aug 2019 12:51:46 +0000 Subject: [issue37914] class timedelta, support the method hours and minutes in field accessors In-Reply-To: <1566470893.59.0.211009594568.issue37914@roundup.psfhosted.org> Message-ID: <1566737506.3.0.306633490034.issue37914@roundup.psfhosted.org> Elinaldo Monteiro added the comment: I am closed my issue. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 09:11:49 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 Aug 2019 13:11:49 +0000 Subject: [issue34880] About the "assert" bytecode In-Reply-To: <1538549910.96.0.545547206417.issue34880@psf.upfronthosting.co.za> Message-ID: <1566738709.48.0.99897305479.issue34880@roundup.psfhosted.org> Serhiy Storchaka added the comment: Thank you Zackery for your contribution. > where ".AssertionError" is a name-mangled free variable and is assigned once the module is executed. But this still allows to overriding builtin AssertionError before importing a module. And this solution would be much more complex that adding a new opcode. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 09:21:03 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 25 Aug 2019 13:21:03 +0000 Subject: [issue30162] Add _PyTuple_Empty and make PyTuple_New(0) never failing In-Reply-To: <1493139112.34.0.200828606997.issue30162@psf.upfronthosting.co.za> Message-ID: <1566739263.92.0.0209972451156.issue30162@roundup.psfhosted.org> Serhiy Storchaka added the comment: Closed because several commenters found things to not like about it. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 09:24:16 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 25 Aug 2019 13:24:16 +0000 Subject: [issue37940] Add xml.tool to pretty print XML like json.tool In-Reply-To: <1566658533.41.0.722111821042.issue37940@roundup.psfhosted.org> Message-ID: <1566739456.66.0.852917272432.issue37940@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: There are several modules that expose some of their uses through command line like json.tool, zipfile, tarfile, gzip, webbrowser etc. The initial proposal was to expose the newly added indent function over the command line to provide the same guarantees and semantics. The lxml link lead me to have xpath search looks more useful to me. I understand that there was always discussion over writing few lines of Python code to do the task and to achieve it via command line. Recent addition were around * --json-lines added to json.tool in issue31553 * Add --fast, --best to gzip CLI in issue34969 There were similar discussion where improvements were merged on a case by case basis as seen to be a good use case. Some where more on the side of rejection like --indent to specify indentation length for json.tool in issue29636. There was no xml.tool in the past so there is more consideration to this. I see it good that xml also can expose some of its tasks via command line and not to be left just because it never had a command line interface from the start. The command line API also exposes only the functions already present so I see the maintenance cost to be minimal with indent and xpath search in this case. I will leave it to you as per the examples and use cases mentioned. If it needs a wider discussion on posting to python-ideas/discourse I would be okay to start a thread . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 09:41:13 2019 From: report at bugs.python.org (Origami Tobiichi) Date: Sun, 25 Aug 2019 13:41:13 +0000 Subject: [issue37944] About json.load(s Message-ID: <1566740473.44.0.553990225097.issue37944@roundup.psfhosted.org> Change by Origami Tobiichi : ---------- components: Extension Modules nosy: Origami Tobiichi priority: normal severity: normal status: open title: About json.load(s type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 09:45:43 2019 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 25 Aug 2019 13:45:43 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1566740743.59.0.444229162188.issue37757@roundup.psfhosted.org> Nick Coghlan added the comment: New changeset 5dbe0f59b7a4f39c7c606b48056bc29e406ebf78 by Nick Coghlan in branch 'master': bpo-37757: Disallow PEP 572 cases that expose implementation details (GH-15131) https://github.com/python/cpython/commit/5dbe0f59b7a4f39c7c606b48056bc29e406ebf78 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 09:46:00 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 25 Aug 2019 13:46:00 +0000 Subject: [issue37944] About json.load(s Message-ID: <1566740760.76.0.656631559349.issue37944@roundup.psfhosted.org> New submission from Karthikeyan Singaravelan : Can you please add a description to explain the report? ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 09:54:38 2019 From: report at bugs.python.org (Origami Tobiichi) Date: Sun, 25 Aug 2019 13:54:38 +0000 Subject: [issue37944] Adjacent escape character in json.load() In-Reply-To: <1566740760.76.0.656631559349.issue37944@roundup.psfhosted.org> Message-ID: <1566741278.95.0.927003838534.issue37944@roundup.psfhosted.org> Origami Tobiichi added the comment: I tried something like this: ```python print(r'{"foo": "\\\""}') print('{"foo": "\\\""}') print(json.loads(r'{"foo":"\\\""}')) ``` On my machine it output like this: ``` {"foo": "\\\""} {"foo": "\""} {'foo': '\\"'} ``` But in most of online json parser, string `{"foo": "\\\""}` will be parsed as `{"foo":"\""}` I'm not a specialist of JSON at all. If the standard of JSON hasn't said anything of it, please point it out in Python's Document at least. When I ask my friend to run the code, he got the same result as me. And my friend is using lastest Arch Linux at that time(2019/08/26). My python version: 3.7.4 System version: Linux 4.19.66-1-MANJARO ---------- nosy: -xtreak title: About json.load(s -> Adjacent escape character in json.load() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 10:00:28 2019 From: report at bugs.python.org (Origami Tobiichi) Date: Sun, 25 Aug 2019 14:00:28 +0000 Subject: [issue37944] Adjacent escape character in json.load() In-Reply-To: <1566740760.76.0.656631559349.issue37944@roundup.psfhosted.org> Message-ID: <1566741628.63.0.134736195691.issue37944@roundup.psfhosted.org> Origami Tobiichi added the comment: I hope I have given enough infomations. And I'm not good at English, please forgive some of my spell wrong, thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 10:01:36 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Sun, 25 Aug 2019 14:01:36 +0000 Subject: [issue37837] add internal _PyLong_FromUnsignedChar() function In-Reply-To: <1565692195.8.0.862568192553.issue37837@roundup.psfhosted.org> Message-ID: <1566741696.18.0.829996391244.issue37837@roundup.psfhosted.org> Sergey Fedoseev added the comment: These last results are invalid :-) I thought that I was checking _PyLong_FromUnsignedChar() on top of GH-15192, but that wasn't true. So the correct results for LTO build are: $ python -m perf timeit -s "from collections import deque; consume = deque(maxlen=0).extend; b = bytes(2**20)" "consume(b)" --compare-to=../cpython-master/venv/bin/python /home/sergey/tmp/cpython-master/venv/bin/python: ..................... 6.93 ms +- 0.04 ms /home/sergey/tmp/cpython-dev/venv/bin/python: ..................... 3.96 ms +- 0.01 ms Mean +- std dev: [/home/sergey/tmp/cpython-master/venv/bin/python] 6.93 ms +- 0.04 ms -> [/home/sergey/tmp/cpython-dev/venv/bin/python] 3.96 ms +- 0.01 ms: 1.75x faster (-43%) But the most important thing is that using PyLong_FromUnsignedLong() instead of _PyLong_FromUnsignedChar() on top of GH-15192 is producing the same results: striter_next() uses small_ints[] directly. However that's not true for bytearrayiter_next(): PyLong_FromUnsignedLong() is called there. I think that's due to how code is profiled so I'm satisfied with these results more or less. I'm closing existing PR and probably will close this issue soon after GH-15192 will be merged. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 10:10:49 2019 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 25 Aug 2019 14:10:49 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1566742249.13.0.610501193962.issue37757@roundup.psfhosted.org> Change by Nick Coghlan : ---------- pull_requests: +15178 pull_request: https://github.com/python/cpython/pull/15491 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 10:22:27 2019 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 25 Aug 2019 14:22:27 +0000 Subject: [issue37938] refactor PyLong_As*() functions In-Reply-To: <1566646130.69.0.631400652637.issue37938@roundup.psfhosted.org> Message-ID: <1566742947.81.0.811335108441.issue37938@roundup.psfhosted.org> Change by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 10:41:50 2019 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 25 Aug 2019 14:41:50 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1566744110.84.0.026172275491.issue37757@roundup.psfhosted.org> Nick Coghlan added the comment: New changeset 6ca030765db49525f16b8fabff4153238148b58d by Nick Coghlan in branch '3.8': [3.8] bpo-37757: Disallow PEP 572 cases that expose implementation details (GH-15491) https://github.com/python/cpython/commit/6ca030765db49525f16b8fabff4153238148b58d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 10:43:28 2019 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 25 Aug 2019 14:43:28 +0000 Subject: [issue37757] TargetScopeError not raised for comprehension scope conflict In-Reply-To: <1564964102.91.0.387603674091.issue37757@roundup.psfhosted.org> Message-ID: <1566744208.49.0.754419206329.issue37757@roundup.psfhosted.org> Nick Coghlan added the comment: Merged for 3.8b4 after Emily's review. Thanks to all involved in the PEP update and change discussion! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 11:01:38 2019 From: report at bugs.python.org (Dong-hee Na) Date: Sun, 25 Aug 2019 15:01:38 +0000 Subject: [issue24479] Support LMMS project files in mimetypes.guess_type In-Reply-To: <1434795502.53.0.948243693094.issue24479@psf.upfronthosting.co.za> Message-ID: <1566745298.99.0.959756704842.issue24479@roundup.psfhosted.org> Dong-hee Na added the comment: @vstiner I'd like to work on this issue. My plan is adding mime-types as 'mmp' to 'application/x-lmms-project' and 'mmpz' to 'application/x-lmms-project' What do you think? ---------- nosy: +corona10 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 11:12:05 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 25 Aug 2019 15:12:05 +0000 Subject: [issue34769] _asyncgen_finalizer_hook running in wrong thread In-Reply-To: <1537627184.81.0.956365154283.issue34769@psf.upfronthosting.co.za> Message-ID: <1566745925.03.0.906096253438.issue34769@roundup.psfhosted.org> Change by Andrew Svetlov : ---------- pull_requests: +15179 pull_request: https://github.com/python/cpython/pull/15492 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 11:14:55 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 25 Aug 2019 15:14:55 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566746095.96.0.602707347781.issue34679@roundup.psfhosted.org> Andrew Svetlov added the comment: The issue is related to Python 3.8 and master only. 3.6-3.7 are not affected ---------- versions: +Python 3.9 -Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 11:15:38 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 25 Aug 2019 15:15:38 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566746138.45.0.940300992059.issue34679@roundup.psfhosted.org> Andrew Svetlov added the comment: Kyle, thanks for the fix. I have basically the same change in my PR but with test and news note. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 11:15:56 2019 From: report at bugs.python.org (Origami Tobiichi) Date: Sun, 25 Aug 2019 15:15:56 +0000 Subject: [issue37944] Adjacent escape character in json.load() In-Reply-To: <1566740760.76.0.656631559349.issue37944@roundup.psfhosted.org> Message-ID: <1566746156.59.0.247147675727.issue37944@roundup.psfhosted.org> Origami Tobiichi added the comment: I'm sorry that I remove you from list, actually it's my first time to commit an issue on there and I'm afraid I used it wrong. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 11:16:39 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 25 Aug 2019 15:16:39 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566746199.04.0.504659144556.issue34679@roundup.psfhosted.org> Change by Andrew Svetlov : ---------- keywords: +patch pull_requests: +15180 pull_request: https://github.com/python/cpython/pull/15492 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 11:42:34 2019 From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=) Date: Sun, 25 Aug 2019 15:42:34 +0000 Subject: [issue1152248] Add support for reading records with arbitrary separators to the standard IO stack Message-ID: <1566747754.17.0.391980866569.issue1152248@roundup.psfhosted.org> Change by G?ry : ---------- nosy: +maggyero _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 11:43:27 2019 From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=) Date: Sun, 25 Aug 2019 15:43:27 +0000 Subject: [issue17083] can't specify newline string for readline for binary files In-Reply-To: <1359570725.1.0.7766942653.issue17083@psf.upfronthosting.co.za> Message-ID: <1566747807.74.0.911042523046.issue17083@roundup.psfhosted.org> Change by G?ry : ---------- nosy: +maggyero _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 12:15:24 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 25 Aug 2019 16:15:24 +0000 Subject: [issue34769] _asyncgen_finalizer_hook running in wrong thread In-Reply-To: <1537627184.81.0.956365154283.issue34769@psf.upfronthosting.co.za> Message-ID: <1566749724.97.0.189935365942.issue34769@roundup.psfhosted.org> Change by Andrew Svetlov : ---------- pull_requests: -15179 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 13:33:21 2019 From: report at bugs.python.org (Tim Golden) Date: Sun, 25 Aug 2019 17:33:21 +0000 Subject: [issue37945] test_locale failing Message-ID: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> New submission from Tim Golden : On a Win10 machine I'm consistently seeing test_locale (and test__locale) fail. I'll attach pythoninfo. ====================================================================== ERROR: test_getsetlocale_issue1813 (test.test_locale.TestMiscellaneous) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\tim\work-in-progress\cpython\lib\test\test_locale.py", line 531, in test_getsetlocale_issue1813 locale.setlocale(locale.LC_CTYPE, loc) File "C:\Users\tim\work-in-progress\cpython\lib\locale.py", line 604, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting ---------- assignee: tim.golden components: Library (Lib) files: pythoninfo.txt messages: 350466 nosy: tim.golden priority: normal severity: normal status: open title: test_locale failing type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file48561/pythoninfo.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 13:35:11 2019 From: report at bugs.python.org (Viktor Kovtun) Date: Sun, 25 Aug 2019 17:35:11 +0000 Subject: [issue34014] loop.run_in_executor should propagate current contextvars In-Reply-To: <1530401184.74.0.56676864532.issue34014@psf.upfronthosting.co.za> Message-ID: <1566754511.32.0.92965660054.issue34014@roundup.psfhosted.org> Viktor Kovtun added the comment: Hey, as I see there is no new API yet. Can we take a look again on 3) ? I'll be happy to update PR 9688 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 13:45:32 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Sun, 25 Aug 2019 17:45:32 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566755132.85.0.568664614972.issue37945@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- components: +Windows nosy: +eryksun, paul.moore, steve.dower, xtreak, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 14:02:32 2019 From: report at bugs.python.org (Netzeband) Date: Sun, 25 Aug 2019 18:02:32 +0000 Subject: [issue37835] typing.get_type_hints wrong namespace for forward-declaration of inner class In-Reply-To: <1565689003.91.0.0312877377737.issue37835@roundup.psfhosted.org> Message-ID: <1566756152.9.0.312994677565.issue37835@roundup.psfhosted.org> Netzeband added the comment: I think I found a better workaround (by accident). I was debugging another issue with get_type_hints for the case that this function is used inside the __new__ method of a metaclass and with methods of the class to define. Here the same issue happens: Forward declared type names are not inside the namespace of the function. However, inside the __new__ method of the metaclass, you already know the name of the class you want to define and you know the class-object to define. With this information it is very easy to add the missing reference to the __globals__ list of all methods found in the namespace. So the workaround is to use a metaclass, which adds the class-name and class-object to the global namespace of the methods of this class. It works also in case of classes, which are inherited, from a class, which uses this metaclass. This leads also to a non-workaround solution: Why is the own class not always inside the __globals__ list of the methods? Is there a reason? Or is this just a missing feature of the python-core? What are you thinking about this solution? Do you see any issues or corner-cases with that? Working code is attached to this ticket (metaclass_workaround.py) ---------- Added file: https://bugs.python.org/file48562/metaclass_workaround.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 14:43:19 2019 From: report at bugs.python.org (hongweipeng) Date: Sun, 25 Aug 2019 18:43:19 +0000 Subject: [issue37806] Infinite recursion with typing.get_type_hints In-Reply-To: <1565414817.02.0.248356075738.issue37806@roundup.psfhosted.org> Message-ID: <1566758599.44.0.205804900838.issue37806@roundup.psfhosted.org> Change by hongweipeng : ---------- keywords: +patch pull_requests: +15181 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15493 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 15:06:49 2019 From: report at bugs.python.org (Berker Peksag) Date: Sun, 25 Aug 2019 19:06:49 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1566760009.19.0.516732555731.issue29553@roundup.psfhosted.org> Berker Peksag added the comment: New changeset da27d9b9dc44913ffee8f28d9638985eaaa03755 by Berker Peksag (Flavian Hautbois) in branch 'master': bpo-29553: Fix ArgumentParser.format_usage() for mutually exclusive groups (GH-14976) https://github.com/python/cpython/commit/da27d9b9dc44913ffee8f28d9638985eaaa03755 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 15:07:00 2019 From: report at bugs.python.org (miss-islington) Date: Sun, 25 Aug 2019 19:07:00 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1566760020.62.0.550186891032.issue29553@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15182 pull_request: https://github.com/python/cpython/pull/15494 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 15:29:13 2019 From: report at bugs.python.org (Tim Golden) Date: Sun, 25 Aug 2019 19:29:13 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566761353.12.0.105494276883.issue37945@roundup.psfhosted.org> Tim Golden added the comment: Ok; so basically this doesn't work: import locale locale.setlocale(locale.LC_CTYPE, locale.getdefaultlocale()) It gives "locale.Error: unsupported locale setting" which comes from https://github.com/python/cpython/blob/master/Modules/_localemodule.c#L107 (For locale.getdefaultlocale() you could substitute locale.getlocale() or simply ("en_GB", "cp1252")). On my machine it raises that exception on Python 2.7.15, 3.6.6 and on master. Interestingly, none of the other tests in test_locale appear to exercise the 2-tuple 2nd param to setlocale. When you call setlocale and it returns the previous setting, it's a single string, eg "en_GB" etc. Passing that back in works. But when you call getlocale, it returns the 2-tuple, eg ("en_GB", "cp1252"). But all the other tests use the setlocale-returns-current trick for their setup/teardown. I've quickly tested on 3.5 on Linux and the 2-tuple version works ok. I assume it's working on buildbots or we'd see the Turkish test failing every time. So is there something different about my C runtime, I wonder? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 15:34:05 2019 From: report at bugs.python.org (Tim Golden) Date: Sun, 25 Aug 2019 19:34:05 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566761645.44.0.98914835325.issue37945@roundup.psfhosted.org> Tim Golden added the comment: Just to save you looking, the code in https://github.com/python/cpython/blob/master/Modules/_localemodule.c#L107 converts the 2-tuple to lang.encoding form so the C module is seeing "en_GB.cp1252" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 16:36:46 2019 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 25 Aug 2019 20:36:46 +0000 Subject: [issue37806] Infinite recursion with typing.get_type_hints In-Reply-To: <1565414817.02.0.248356075738.issue37806@roundup.psfhosted.org> Message-ID: <1566765406.16.0.377717123701.issue37806@roundup.psfhosted.org> Change by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 16:47:24 2019 From: report at bugs.python.org (Kyle Stanley) Date: Sun, 25 Aug 2019 20:47:24 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566766044.21.0.394203243786.issue34679@roundup.psfhosted.org> Kyle Stanley added the comment: > Kyle, thanks for the fix. > I have basically the same change in my PR but with test and news note. No problem, that works for me. I was mostly just trying to help with resolving some of the release blockers for 3.8b4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 17:30:57 2019 From: report at bugs.python.org (Berker Peksag) Date: Sun, 25 Aug 2019 21:30:57 +0000 Subject: [issue29553] Argparser does not display closing parentheses in nested mutex groups In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za> Message-ID: <1566768657.82.0.74256079443.issue29553@roundup.psfhosted.org> Berker Peksag added the comment: New changeset 31ea447ffe591736af1d7a3178c0f7ca3eb50d70 by Berker Peksag (Miss Islington (bot)) in branch '3.7': bpo-29553: Fix ArgumentParser.format_usage() for mutually exclusive groups (GH-14976) https://github.com/python/cpython/commit/31ea447ffe591736af1d7a3178c0f7ca3eb50d70 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 18:36:03 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 25 Aug 2019 22:36:03 +0000 Subject: [issue34769] _asyncgen_finalizer_hook running in wrong thread In-Reply-To: <1537627184.81.0.956365154283.issue34769@psf.upfronthosting.co.za> Message-ID: <1566772563.71.0.269534932417.issue34769@roundup.psfhosted.org> Change by Andrew Svetlov : ---------- pull_requests: +15183 pull_request: https://github.com/python/cpython/pull/15492 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 18:36:03 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 25 Aug 2019 22:36:03 +0000 Subject: [issue34769] _asyncgen_finalizer_hook running in wrong thread In-Reply-To: <1537627184.81.0.956365154283.issue34769@psf.upfronthosting.co.za> Message-ID: <1566772563.84.0.111447020402.issue34769@roundup.psfhosted.org> Change by Andrew Svetlov : ---------- pull_requests: +15183, 15184, 15185 pull_request: https://github.com/python/cpython/pull/15492 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 18:36:03 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Sun, 25 Aug 2019 22:36:03 +0000 Subject: [issue34769] _asyncgen_finalizer_hook running in wrong thread In-Reply-To: <1537627184.81.0.956365154283.issue34769@psf.upfronthosting.co.za> Message-ID: <1566772563.79.0.272752198955.issue34769@roundup.psfhosted.org> Change by Andrew Svetlov : ---------- pull_requests: +15183, 15184 pull_request: https://github.com/python/cpython/pull/15492 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 18:47:51 2019 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 25 Aug 2019 22:47:51 +0000 Subject: [issue37827] IDLE: Have the shell mimic terminal handling of \r and \b control characters in outputs In-Reply-To: <1565592773.8.0.657523892243.issue37827@roundup.psfhosted.org> Message-ID: <1566773271.77.0.473066202152.issue37827@roundup.psfhosted.org> Guido van Rossum added the comment: I agree -- this was added to Emacs a long time ago and it makes a big difference for people (like myself) who do a lot of work in Emacs shell windows. I imagine it's the same for IDLE. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 19:25:41 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Sun, 25 Aug 2019 23:25:41 +0000 Subject: [issue23933] Struct module should accept arrays In-Reply-To: <1428935151.96.0.568768704224.issue23933@psf.upfronthosting.co.za> Message-ID: <1566775541.67.0.250545083243.issue23933@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- title: Struct module should acept arrays -> Struct module should accept arrays _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 19:43:44 2019 From: report at bugs.python.org (Kyle Stanley) Date: Sun, 25 Aug 2019 23:43:44 +0000 Subject: [issue23933] Struct module should accept arrays In-Reply-To: <1428935151.96.0.568768704224.issue23933@psf.upfronthosting.co.za> Message-ID: <1566776624.59.0.790016974482.issue23933@roundup.psfhosted.org> Change by Kyle Stanley : ---------- nosy: +mark.dickinson, meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 19:53:51 2019 From: report at bugs.python.org (Eryk Sun) Date: Sun, 25 Aug 2019 23:53:51 +0000 Subject: [issue20806] os.times document points to wrong section of non-Linux manual In-Reply-To: <1393590805.13.0.860460942185.issue20806@psf.upfronthosting.co.za> Message-ID: <1566777231.85.0.772319743886.issue20806@roundup.psfhosted.org> Eryk Sun added the comment: The function's doc string also needs to be updated to use the correct field names: "user", "system", "children_user", "children_system", and "elapsed". > And we can also add a link to MSDN. os.times calls GetProcessTimes [1]. The user and kernel process times are incremented in clock ticks, i.e. in integer multiples of the system clock interrupt time. QueryUnbiasedInterruptTime [2] could thus be used for the value of `elapsed`. (Windows doesn't implement a process tree for the children_user and children_system values. It has jobs, which are similar to Linux control groups, but jobs aren't applicable here. POSIX doesn't have anything like Windows jobs or Linux cgroups.) [1] https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getprocesstimes [2] https://docs.microsoft.com/en-us/windows/win32/api/realtimeapiset/nf-realtimeapiset-queryunbiasedinterrupttime ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 21:42:30 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 26 Aug 2019 01:42:30 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566641380.85.0.479847824834.issue37884@roundup.psfhosted.org> Message-ID: <20190826014221.GA25893@ando.pearwood.info> Steven D'Aprano added the comment: On Sat, Aug 24, 2019 at 10:09:40AM +0000, Serhiy Storchaka wrote: > Could you please explain what is wrong in adding a helper function > which will help to convert different types of numbers to integer ratio > correctly? > > Currently you need to write a complex code if you need to convert a > general number to integer ratio: When I first wrote the statistics module, I found that converting to fractions was a bottleneck. I spent some time tweaking the private _exact_ratio() function which is why the code is so hairy. Being able to simplify and speed up that conversion would be great, and I thank Serhiy for looking at this. But I am concerned about the API, writing a *private* helper function in the math module, but then using it in the statistics module as if it were public. That will surely encourage people to do the same, and before long this private helper will have to be treated as public. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 22:16:05 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Mon, 26 Aug 2019 02:16:05 +0000 Subject: [issue32847] Add DirectoryNotEmptyError subclass of OSError In-Reply-To: <1518664317.8.0.467229070634.issue32847@psf.upfronthosting.co.za> Message-ID: <1566785765.2.0.0629152529627.issue32847@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- keywords: +patch pull_requests: +15186 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15496 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 22:29:39 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 02:29:39 +0000 Subject: [issue37946] Add the Bessel functions of the first and second kind to the math module Message-ID: <1566786579.57.0.437396852549.issue37946@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : After repeatedly having to add 3rd party libraries only for the these functions or having to implement them myself quick and dirty based on numerical integration, I suggest add the Bessel functions of the first and second kind to the math module. These functions tend to appear a lot (but not restricted to) when evaluating systems that are defined on cylindrical geometries, restrictions or approximations (like the proximate solution to Kepler's equation as a truncated Fourier sine series) and many other special functions can be described as series involving them. Based on the fact that many libc implementations include them I think the cost-benefit of exposing them when available is acceptable. ---------- components: Extension Modules messages: 350477 nosy: mark.dickinson, pablogsal, rhettinger priority: normal severity: normal status: open title: Add the Bessel functions of the first and second kind to the math module type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 22:34:30 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 02:34:30 +0000 Subject: [issue37946] Add the Bessel functions of the first and second kind to the math module In-Reply-To: <1566786579.57.0.437396852549.issue37946@roundup.psfhosted.org> Message-ID: <1566786870.18.0.453382636424.issue37946@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +15187 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15497 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 23:09:10 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 03:09:10 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level Message-ID: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : The symtable_handle_namedexpr function does not adjust correctly the recursion level when exiting (also, is actually not returning anything in a function defined as non-void but the return value is not used so is not technically undefined behavior). ---------- components: Interpreter Core messages: 350478 nosy: pablogsal priority: normal severity: normal status: open title: symtable_handle_namedexpr does not adjust correctly the recursion level versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 23:10:55 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 03:10:55 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level In-Reply-To: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> Message-ID: <1566789055.87.0.637828256638.issue37947@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +15188 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15499 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 23:16:34 2019 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 26 Aug 2019 03:16:34 +0000 Subject: [issue37946] Add the Bessel functions of the first and second kind to the math module In-Reply-To: <1566786579.57.0.437396852549.issue37946@roundup.psfhosted.org> Message-ID: <1566789394.77.0.706350403675.issue37946@roundup.psfhosted.org> Steven D'Aprano added the comment: If they are provided by the C lib, I would love to see them exposed by Python. If they aren't, I don't know if they should be treated as optional/platform dependent, or if we should provide an independent implementation. I guess the easy way is to just make it optional. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 23:23:54 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 03:23:54 +0000 Subject: [issue37946] Add the Bessel functions of the first and second kind to the math module In-Reply-To: <1566786579.57.0.437396852549.issue37946@roundup.psfhosted.org> Message-ID: <1566789834.14.0.624000974993.issue37946@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: > If they are provided by the C lib, I would love to see them exposed by Python. Check PR 15497 for an initial version of exposing the libm functions if they are available. > I don't know if they should be treated as optional/platform dependent, or if we should provide an independent implementation. Even if we want to provide an independent implementation, I would suggest to separate the two steps and starting to expose the underliying ones if they are available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Aug 25 23:47:02 2019 From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=) Date: Mon, 26 Aug 2019 03:47:02 +0000 Subject: [issue37934] Docs: Clarify NotImplemented use cases In-Reply-To: <1566596946.3.0.57144717386.issue37934@roundup.psfhosted.org> Message-ID: <1566791222.92.0.541603623165.issue37934@roundup.psfhosted.org> Vedran ?a?i? added the comment: Well, it is the _intended_ use of NotImplemented. Of course you can use it whenever you want, just as you can use Ellipsis whenever you want. But I don't think docs should encourage that. ---------- nosy: +veky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 00:26:49 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Aug 2019 04:26:49 +0000 Subject: [issue37934] Docs: Clarify NotImplemented use cases In-Reply-To: <1566596946.3.0.57144717386.issue37934@roundup.psfhosted.org> Message-ID: <1566793609.56.0.783170218578.issue37934@roundup.psfhosted.org> Raymond Hettinger added the comment: It is not the purpose of the docs to list use cases. Mostly we say what something does or how it is defined. As Vedran says, how people use it is their own business. Also, please be careful expanded the docs. They quickly become a promise. Per Doc/reference/introduction.rst, "It is dangerous to add too many implementation details to a language reference document --- the implementation may change, and other implementations of the same language may work differently." ---------- nosy: +rhettinger resolution: -> rejected stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 00:44:19 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 26 Aug 2019 04:44:19 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1566794659.15.0.229806698617.issue37824@roundup.psfhosted.org> Change by Terry J. Reedy : ---------- pull_requests: +15189 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15500 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 00:48:21 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 26 Aug 2019 04:48:21 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1566794901.66.0.59219887928.issue37824@roundup.psfhosted.org> Terry J. Reedy added the comment: I pulled the part of PR 15311 that works, stop turning Shell SyntaxWarnings into SyntaxErrors, into PR-15500, to get it into b4. I will update the former after merging the latter. ---------- stage: patch review -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 00:50:12 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Aug 2019 04:50:12 +0000 Subject: [issue13653] reorder set.intersection parameters for better performance In-Reply-To: <1324601653.94.0.248406097539.issue13653@psf.upfronthosting.co.za> Message-ID: <1566795012.94.0.94046440184.issue13653@roundup.psfhosted.org> Raymond Hettinger added the comment: The anti-correlation algorithm seems like a plausible heuristic but it can't really know more than the user does about the semantic content of the sets. Also as Terry pointed out, this will have user visible effects. This likely should be published as a blog post or recipe. A user can already control the pairing order and do this or something like it themselves. It is more of a technique for using sets that it is a core set algorithm (it reminds me of using associativity to optimize chained matrix multiplications, though than can be done precisely rather than heuristically). ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 01:11:17 2019 From: report at bugs.python.org (Eryk Sun) Date: Mon, 26 Aug 2019 05:11:17 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566796277.17.0.314381965288.issue37945@roundup.psfhosted.org> Eryk Sun added the comment: local.normalize is generally wrong in Windows. It's meant for POSIX systems. Currently "tr_TR" is parsed as follows: >>> locale._parse_localename('tr_TR') ('tr_TR', 'ISO8859-9') The encoding "ISO8859-9" is meaningless to Windows. Also, the old CRT only ever supported either full language/country names or non-standard abbreviations -- e.g. either "Turkish_Turkey" or "trk_TUR". Having locale.getdefaultlocale() return ISO two-letter codes (e.g. "en_GB") was fundamentally wrong for the old CRT. (2.7 will die with this wart.) 3.5+ uses the Universal CRT, which does support standard ISO codes, but only in BCP 47 [1] locale names of the following form: language ISO 639 ["-" script] ISO 15924 ["-" region] ISO 3166-1 BCP 47 locale names have been preferred by Windows for the past 13 years, since Vista was released. Windows extends BCP 47 with a non-standard sort-order field (e.g. "de-Latn-DE_phoneb" is the German language with Latin script in the region of Germany with phone-book sort order). Another departure from strict BCP 47 in Windows is allowing underscore to be used as the delimiter instead of hyphen. In a concession to existing C code, the Universal CRT also supports an encoding suffix in BCP 47 locales, but this can only be either ".utf-8" or ".utf8". (Windows itself does not support specifying an encoding in a locale name, but it's Unicode anyway.) No other encoding is allowed. If ".utf-8" isn't specified, a BCP 47 locale defaults to the locale's ANSI codepage. However, there's no way to convey this in the locale name itself. Also, if a locale is Unicode only (e.g. Hindi), the CRT implicitly uses UTF-8 even without the ".utf-8" suffix. The following are valid BCP 47 locale names in the CRT: "tr", "tr.utf-8", "tr-TR", "tr_TR", "tr_TR.utf8", or "tr-Latn-TR.utf-8". But note that "tr_TR.1254" is not supported. The following shows that omitting the optional "utf-8" encoding in a BCP 47 locale makes the CRT default to the associated ANSI codepage. >>> locale.setlocale(locale.LC_CTYPE, 'tr_TR') 'tr_TR' >>> ucrt.___lc_codepage_func() 1254 C ___lc_codepage_func() queries the codepage of the current locale. We can directly query this codepage for a BCP 47 locale via GetLocaleInfoEx: >>> cpstr = (ctypes.c_wchar * 6)() >>> kernel32.GetLocaleInfoEx('tr-TR', ... LOCALE_IDEFAULTANSICODEPAGE, cpstr, len(cpstr)) 5 >>> cpstr.value '1254' If the result is '0', it's a Unicode-only locale (e.g. 'hi-IN' -- Hindi, India). Recent versions of the CRT use UTF-8 (codepage 65001) for Unicode-only locales: >>> locale.setlocale(locale.LC_CTYPE, 'hi-IN') 'hi-IN' >>> ucrt.___lc_codepage_func() 65001 Here are some example locale tuples that should be supported, given that the CRT continues to support full English locale names and non-standard abbreviations, in addition to the new BCP 47 names: ('tr', None) ('tr_TR', None) ('tr_Latn_TR, None) ('tr_TR', 'utf-8') ('trk_TUR', '1254') ('Turkish_Turkey', '1254') The return value from C setlocale can be normalized to replace hyphen delimiters with underscores, and "utf8" can be normalized as "utf-8". If it's a BCP 47 locale that has no encoding, GetLocaleInfoEx can be called to query the ANSI codepage. UTF-8 can be assumed if it's a Unicode-only locale. As to prefixing a codepage with 'cp', we don't really need to do this. We have aliases defined for most, such as '1252' -> 'cp1252'. But if the 'cp' prefix does get added, then the locale module should at least know to remove it when building a locale name from a tuple. [1] https://tools.ietf.org/rfc/bcp/bcp47.txt ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 01:59:06 2019 From: report at bugs.python.org (Ned Deily) Date: Mon, 26 Aug 2019 05:59:06 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566799146.99.0.729184805555.issue36205@roundup.psfhosted.org> Ned Deily added the comment: Raynmond: > Something in the release build process is triggering this behavior (perhaps PGO). The difference is explained in msg33731. When 3.7+ is built on macoS 10.11.x+ and earlier, clock_gettime is not available and the PEP 564 refactored code falls back to using getrusage as it did correctly prior to 3.7. But there seems to be a bug in the 3.7 refactored fallback code that gives a result about twice as big as seen in the results of either the proposed test case in PR 12287 or, more simply, the test code in the StackOverflow issue cited above (https://stackoverflow.com/questions/55008397/python-3-5-vs-3-7-process-time). The pre-PEP 564 code in 3.6.x and earlier works correctly regardless on what version of macOS Python was built. Since this problem has apparently been around since 3.7.0 with the implementation of PEP 564, it should not act as a release blocker for 3.8.0. But it *really* needs to be fixed. Victor, could you please find some time to look at this? Thanks! ---------- assignee: -> vstinner priority: release blocker -> critical versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 02:27:59 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 26 Aug 2019 06:27:59 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1566800879.72.0.676910714158.issue37824@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset 1039f39c9c6edb4c185856c19316d3a4eb561c38 by Terry Jan Reedy in branch 'master': bpo-37824: Properly handle user input warnings in IDLE shell. (GH-15500) https://github.com/python/cpython/commit/1039f39c9c6edb4c185856c19316d3a4eb561c38 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 02:28:08 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 06:28:08 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1566800888.73.0.559185433013.issue37824@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15190 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15504 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 02:28:14 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 06:28:14 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1566800894.58.0.477896921075.issue37824@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15191 pull_request: https://github.com/python/cpython/pull/15505 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 02:29:12 2019 From: report at bugs.python.org (Arne Recknagel) Date: Mon, 26 Aug 2019 06:29:12 +0000 Subject: [issue37948] get_type_hints fails if there are un-annotated fields in a dataclass Message-ID: <1566800952.19.0.982220665774.issue37948@roundup.psfhosted.org> New submission from Arne Recknagel : When declaring a dataclass with make_dataclass, it is valid to omit type information for fields. __annotations__ understands it and just adds typing.Any, but typing.get_type_hints fails with a cryptic error message: >>> import dataclasses >>> import typing >>> A = dataclasses.make_dataclass('A', ['a_var']) >>> A.__annotations__ {'a_var': 'typing.Any'} >>> typing.get_type_hints(A) Traceback (most recent call last): File "", line 1, in File "/user/venvs/python_3.7/lib/python3.7/typing.py", line 973, in get_type_hints value = _eval_type(value, base_globals, localns) File "/user/venvs/python_3.7/lib/python3.7/typing.py", line 260, in _eval_type return t._evaluate(globalns, localns) File "/user/venvs/python_3.7/lib/python3.7/typing.py", line 464, in _evaluate eval(self.__forward_code__, globalns, localns), File "", line 1, in NameError: name 'typing' is not defined Adding typing.Any explicitly is an obvious workaround: >>> B = dataclasses.make_dataclass('B', [('a_var', typing.Any)]) >>> typing.get_type_hints(B) {'a_var': typing.Any} There is already a bug filed regarding datalcasses and get_type_hints which might be related: https://bugs.python.org/issue34776 ---------- messages: 350488 nosy: arne, eric.smith priority: normal severity: normal status: open title: get_type_hints fails if there are un-annotated fields in a dataclass type: behavior versions: Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 02:29:13 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 26 Aug 2019 06:29:13 +0000 Subject: [issue37946] Add the Bessel functions of the first and second kind to the math module In-Reply-To: <1566786579.57.0.437396852549.issue37946@roundup.psfhosted.org> Message-ID: <1566800953.47.0.145847357099.issue37946@roundup.psfhosted.org> Mark Dickinson added the comment: They're not part of the C standard and they're not provided by all C libraries; we'd have to code our own and add thorough tests for the implementations (as we have for lgamma, gamma, erf, and other functions that may or may not exist in the platform libm). Making them optional is a no-go - you'd end up with code that works on some platforms but not on others. We've always provided fallback implementations in the past. IMO this is the province of things like scipy.special. The Bessel functions (and many others) are already easily available to users of the scientific Python stack. I don't really see a need to have them in core Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 02:39:48 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Aug 2019 06:39:48 +0000 Subject: [issue37949] Create empty __annotations__ dictionaries lazily Message-ID: <1566801588.69.0.745320126697.issue37949@roundup.psfhosted.org> New submission from Raymond Hettinger : Right now, every heap function is given a new annotations dictionary even if annotations aren't used. How about we create these lazily in order to speed-up function creation time, improve start-up time, and save space. >>> def f(): pass >>> def g(): return 1 >>> f.__annotations__ {} >>> g.__annotations__ {} >>> hex(id(f.__annotations__)) '0x109207e40' >>> hex(id(g.__annotations__)) '0x1092296c0' ---------- components: Interpreter Core messages: 350490 nosy: rhettinger priority: low severity: normal status: open title: Create empty __annotations__ dictionaries lazily type: performance versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 02:52:36 2019 From: report at bugs.python.org (Tim Golden) Date: Mon, 26 Aug 2019 06:52:36 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566802356.79.0.840664111614.issue37945@roundup.psfhosted.org> Tim Golden added the comment: Thanks, Eryk. Your explanation is as clear as always. But my question is, then: why is my machine failing this test [the only one which uses this two-part locale] and not the buildbots or (presumably) any other Windows developer? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 02:52:49 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 26 Aug 2019 06:52:49 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1566802369.95.0.45784422926.issue37824@roundup.psfhosted.org> Terry J. Reedy added the comment: New changeset 077887059a5b3d38161dfd74b160c701445a1ef0 by Terry Jan Reedy (Miss Islington (bot)) in branch '3.8': bpo-37824: Properly handle user input warnings in IDLE shell. (GH-15500) https://github.com/python/cpython/commit/077887059a5b3d38161dfd74b160c701445a1ef0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 02:53:15 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Aug 2019 06:53:15 +0000 Subject: [issue15542] Documentation incorrectly suggests __init__ called after direct __new__ call In-Reply-To: <1343946223.73.0.562621858875.issue15542@psf.upfronthosting.co.za> Message-ID: <1566802395.1.0.794461454243.issue15542@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 6b16d938d6d1ccb443815e20e8812deed274dc09 by Raymond Hettinger (Joannah Nanjekye) in branch 'master': bpo-15542: Documentation incorrectly suggests __init__ called after direct __new__ call (GH-15478) https://github.com/python/cpython/commit/6b16d938d6d1ccb443815e20e8812deed274dc09 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 02:53:23 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 06:53:23 +0000 Subject: [issue15542] Documentation incorrectly suggests __init__ called after direct __new__ call In-Reply-To: <1343946223.73.0.562621858875.issue15542@psf.upfronthosting.co.za> Message-ID: <1566802403.23.0.210883199014.issue15542@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15192 pull_request: https://github.com/python/cpython/pull/15506 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 02:53:41 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 06:53:41 +0000 Subject: [issue37824] IDLE: Handle Shell input warnings properly. In-Reply-To: <1565541132.63.0.273797082992.issue37824@roundup.psfhosted.org> Message-ID: <1566802421.03.0.964375115196.issue37824@roundup.psfhosted.org> miss-islington added the comment: New changeset 1b15914ebb46e549ff0965c789ef03b4bac2a890 by Miss Islington (bot) in branch '3.7': bpo-37824: Properly handle user input warnings in IDLE shell. (GH-15500) https://github.com/python/cpython/commit/1b15914ebb46e549ff0965c789ef03b4bac2a890 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:04:38 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 07:04:38 +0000 Subject: [issue37805] json.dump(..., skipkeys=True) has no unit tests In-Reply-To: <1565387683.62.0.51432990737.issue37805@roundup.psfhosted.org> Message-ID: <1566803078.61.0.760009181963.issue37805@roundup.psfhosted.org> miss-islington added the comment: New changeset 44cd86bbdddb1f7b05deba2c1986a1e98f992429 by Miss Islington (bot) (Dong-hee Na) in branch 'master': bpo-37805: Add tests for json.dump(..., skipkeys=True) (GH-15489) https://github.com/python/cpython/commit/44cd86bbdddb1f7b05deba2c1986a1e98f992429 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:04:46 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 07:04:46 +0000 Subject: [issue37805] json.dump(..., skipkeys=True) has no unit tests In-Reply-To: <1565387683.62.0.51432990737.issue37805@roundup.psfhosted.org> Message-ID: <1566803086.54.0.064207901436.issue37805@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15193 pull_request: https://github.com/python/cpython/pull/15507 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:04:58 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 07:04:58 +0000 Subject: [issue37805] json.dump(..., skipkeys=True) has no unit tests In-Reply-To: <1565387683.62.0.51432990737.issue37805@roundup.psfhosted.org> Message-ID: <1566803098.13.0.104998963275.issue37805@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15194 pull_request: https://github.com/python/cpython/pull/15508 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:13:25 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Aug 2019 07:13:25 +0000 Subject: [issue36917] ast.NodeVisitor no longer calls visit_Str In-Reply-To: <1557843682.58.0.0807679622364.issue36917@roundup.psfhosted.org> Message-ID: <1566803605.18.0.853846312537.issue36917@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset c3ea41e9bf100a5396b851488c3efe208e5e2179 by Serhiy Storchaka in branch 'master': bpo-36917: Add default implementation of ast.NodeVisitor.visit_Constant(). (GH-15490) https://github.com/python/cpython/commit/c3ea41e9bf100a5396b851488c3efe208e5e2179 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:13:32 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 07:13:32 +0000 Subject: [issue36917] ast.NodeVisitor no longer calls visit_Str In-Reply-To: <1557843682.58.0.0807679622364.issue36917@roundup.psfhosted.org> Message-ID: <1566803612.72.0.720205730396.issue36917@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15195 pull_request: https://github.com/python/cpython/pull/15509 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:15:41 2019 From: report at bugs.python.org (Dong-hee Na) Date: Mon, 26 Aug 2019 07:15:41 +0000 Subject: [issue33955] Implement PyOS_CheckStack on macOS using pthread_get_stack*_np In-Reply-To: <1529925495.69.0.56676864532.issue33955@psf.upfronthosting.co.za> Message-ID: <1566803741.29.0.459101236277.issue33955@roundup.psfhosted.org> Dong-hee Na added the comment: @ronaldoussoren Do you have any ideas to resume this issue again? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:15:58 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 26 Aug 2019 07:15:58 +0000 Subject: [issue37946] Add the Bessel functions of the first and second kind to the math module In-Reply-To: <1566786579.57.0.437396852549.issue37946@roundup.psfhosted.org> Message-ID: <1566803758.58.0.581676459838.issue37946@roundup.psfhosted.org> Mark Dickinson added the comment: I'd also say that SciPy does this much better than the Python math library could ever hope to (without that math library effectively becoming a copy of scipy.special). It probably wouldn't be long before a user of the new Bessel functions also wanted Bessel functions of half-integer order (which turn up in statistics and in spherical harmonics problems), or of arbitrary complex order, or modified Bessel functions, or Airy functions and elliptic integrals, or ... For all those cases, SciPy has you covered, but extending the math module to cover all these things would be a lot of work and an unnecessary (IMO) duplication of effort. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:16:21 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 26 Aug 2019 07:16:21 +0000 Subject: [issue37946] Add the Bessel functions of the first and second kind to the math module In-Reply-To: <1566786579.57.0.437396852549.issue37946@roundup.psfhosted.org> Message-ID: <1566803781.97.0.00982982651122.issue37946@roundup.psfhosted.org> Change by Mark Dickinson : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:16:42 2019 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 26 Aug 2019 07:16:42 +0000 Subject: [issue37946] Add the Bessel functions of the first and second kind to the math module In-Reply-To: <1566786579.57.0.437396852549.issue37946@roundup.psfhosted.org> Message-ID: <1566803802.74.0.187568093016.issue37946@roundup.psfhosted.org> Mark Dickinson added the comment: Tim, Raymond: thoughts? I'm inclined to close this as rejected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:17:47 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Aug 2019 07:17:47 +0000 Subject: [issue27575] dict viewkeys intersection slow for large dicts In-Reply-To: <1468950707.74.0.640405379684.issue27575@psf.upfronthosting.co.za> Message-ID: <1566803867.04.0.401353094659.issue27575@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 998cf1f03a61de8a0cd3811faa97973d4022bc55 by Raymond Hettinger (Forest Gregg) in branch 'master': bpo-27575: port set intersection logic into dictview intersection (GH-7696) https://github.com/python/cpython/commit/998cf1f03a61de8a0cd3811faa97973d4022bc55 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:18:50 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Aug 2019 07:18:50 +0000 Subject: [issue27575] dict viewkeys intersection slow for large dicts In-Reply-To: <1468950707.74.0.640405379684.issue27575@psf.upfronthosting.co.za> Message-ID: <1566803930.55.0.139662196112.issue27575@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks David and Forest. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:19:23 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Aug 2019 07:19:23 +0000 Subject: [issue15542] Documentation incorrectly suggests __init__ called after direct __new__ call In-Reply-To: <1343946223.73.0.562621858875.issue15542@psf.upfronthosting.co.za> Message-ID: <1566803963.46.0.322588266579.issue15542@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset c841fb9e065c393bba5d5505238f7e286f1dcfc6 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-15542: Documentation incorrectly suggests __init__ called after direct __new__ call (GH-15478) (GH-15506) https://github.com/python/cpython/commit/c841fb9e065c393bba5d5505238f7e286f1dcfc6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:20:23 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Aug 2019 07:20:23 +0000 Subject: [issue15542] Documentation incorrectly suggests __init__ called after direct __new__ call In-Reply-To: <1343946223.73.0.562621858875.issue15542@psf.upfronthosting.co.za> Message-ID: <1566804023.96.0.693138726908.issue15542@roundup.psfhosted.org> Raymond Hettinger added the comment: Thanks everyone. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:27:34 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 07:27:34 +0000 Subject: [issue37805] json.dump(..., skipkeys=True) has no unit tests In-Reply-To: <1565387683.62.0.51432990737.issue37805@roundup.psfhosted.org> Message-ID: <1566804454.72.0.874593858408.issue37805@roundup.psfhosted.org> miss-islington added the comment: New changeset a3875171d746f90f49adfcaa015525b20a3874d3 by Miss Islington (bot) in branch '3.8': bpo-37805: Add tests for json.dump(..., skipkeys=True) (GH-15489) https://github.com/python/cpython/commit/a3875171d746f90f49adfcaa015525b20a3874d3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:35:17 2019 From: report at bugs.python.org (Inada Naoki) Date: Mon, 26 Aug 2019 07:35:17 +0000 Subject: [issue37805] json.dump(..., skipkeys=True) has no unit tests In-Reply-To: <1565387683.62.0.51432990737.issue37805@roundup.psfhosted.org> Message-ID: <1566804917.88.0.35417525298.issue37805@roundup.psfhosted.org> Inada Naoki added the comment: thanks ---------- nosy: +inada.naoki resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:35:54 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Aug 2019 07:35:54 +0000 Subject: [issue37950] ast.dump() with incomplete node Message-ID: <1566804954.58.0.654310469231.issue37950@roundup.psfhosted.org> New submission from Serhiy Storchaka : There are several issues in ast.dump() with incompletely initialized node. Some fields and attributes of AST nodes are optional, but creating an AST node without them leads ast.dump() to fail or to produce incorrect result. 1. With annotate_fields=False ast.dump() outputs subnodes as positional arguments of the node constructor. >>> ast.dump(ast.Raise(exc=ast.Name(id='a', ctx=ast.Load()), cause=ast.Name(id='b', ctx=ast.Load())), annotate_fields=False) "Raise(Name('a', Load()), Name('b', Load()))" But if miss the optional exc field it outputs incorrect output: >>> ast.dump(ast.Raise(cause=ast.Name(id='a', ctx=ast.Load())), annotate_fields=False) "Raise(Name('a', Load()))" which is not distinguished from the case when you pass only the exc field and miss the cause field (both are optional): >>> ast.dump(ast.Raise(exc=ast.Name(id='a', ctx=ast.Load())), annotate_fields=False) "Raise(Name('a', Load()))" 2. The documentation of ast.dump() says that its result with annotate_fields=True is impossible to evaluate, but this is not true, because keyword arguments are supported by AST node constructors. 3. Attributes end_lineno and end_col_offset are optional, but if you miss them ast.dump() with include_attributes=True will fail: >>> ast.dump(ast.Raise(lineno=3, col_offset=4), include_attributes=True) Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython3.8/Lib/ast.py", line 126, in dump return _format(node) File "/home/serhiy/py/cpython3.8/Lib/ast.py", line 118, in _format rv += ', '.join('%s=%s' % (a, _format(getattr(node, a))) File "/home/serhiy/py/cpython3.8/Lib/ast.py", line 118, in rv += ', '.join('%s=%s' % (a, _format(getattr(node, a))) AttributeError: 'Raise' object has no attribute 'end_lineno' 4. Even if you specify all attributes, the output looks weird if you do not specify any field (note a space after "("): >>> ast.dump(ast.Raise(lineno=3, col_offset=4, end_lineno=3, end_col_offset=24), include_attributes=True) 'Raise( lineno=3, col_offset=4, end_lineno=3, end_col_offset=24)' ---------- assignee: serhiy.storchaka components: Library (Lib) messages: 350506 nosy: serhiy.storchaka priority: normal severity: normal status: open title: ast.dump() with incomplete node type: behavior versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:36:40 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 07:36:40 +0000 Subject: [issue37805] json.dump(..., skipkeys=True) has no unit tests In-Reply-To: <1565387683.62.0.51432990737.issue37805@roundup.psfhosted.org> Message-ID: <1566805000.57.0.673653851935.issue37805@roundup.psfhosted.org> miss-islington added the comment: New changeset a976283821ab73ba080da47cbe95802ce66bb0a4 by Miss Islington (bot) in branch '3.7': bpo-37805: Add tests for json.dump(..., skipkeys=True) (GH-15489) https://github.com/python/cpython/commit/a976283821ab73ba080da47cbe95802ce66bb0a4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:43:39 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Aug 2019 07:43:39 +0000 Subject: [issue36917] ast.NodeVisitor no longer calls visit_Str In-Reply-To: <1557843682.58.0.0807679622364.issue36917@roundup.psfhosted.org> Message-ID: <1566805419.37.0.792531209549.issue36917@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 522a394a72f107ca55701371529b5e4ed20c9fff by Serhiy Storchaka (Miss Islington (bot)) in branch '3.8': [3.8] bpo-36917: Add default implementation of ast.NodeVisitor.visit_Constant(). (GH-15490) (GH-15509) https://github.com/python/cpython/commit/522a394a72f107ca55701371529b5e4ed20c9fff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:48:37 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Aug 2019 07:48:37 +0000 Subject: [issue37950] ast.dump() with incomplete node In-Reply-To: <1566804954.58.0.654310469231.issue37950@roundup.psfhosted.org> Message-ID: <1566805717.25.0.842014078127.issue37950@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +15196 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15510 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 03:53:12 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Aug 2019 07:53:12 +0000 Subject: [issue36917] ast.NodeVisitor no longer calls visit_Str In-Reply-To: <1557843682.58.0.0807679622364.issue36917@roundup.psfhosted.org> Message-ID: <1566805992.85.0.658393285153.issue36917@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +15197 pull_request: https://github.com/python/cpython/pull/15511 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 04:05:15 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Aug 2019 08:05:15 +0000 Subject: [issue37949] Create empty __annotations__ dictionaries lazily In-Reply-To: <1566801588.69.0.745320126697.issue37949@roundup.psfhosted.org> Message-ID: <1566806715.9.0.442575224012.issue37949@roundup.psfhosted.org> Serhiy Storchaka added the comment: Guido's Time Machine strikes back. >>> import gc >>> def f(): pass ... >>> gc.get_referents(f) [", line 1>, {'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': , '__spec__': None, '__annotations__': {}, '__builtins__': , 'gc': , 'f': }, '__main__', None, 'f', 'f'] >>> f.__annotations__ {} >>> gc.get_referents(f) [", line 1>, {'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': , '__spec__': None, '__annotations__': {}, '__builtins__': , 'gc': , 'f': }, '__main__', None, 'f', {}, 'f'] ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 04:08:07 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Aug 2019 08:08:07 +0000 Subject: [issue32847] Add DirectoryNotEmptyError subclass of OSError In-Reply-To: <1518664317.8.0.467229070634.issue32847@psf.upfronthosting.co.za> Message-ID: <1566806887.33.0.283682282381.issue32847@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +pitrou versions: +Python 3.9 -Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 04:16:44 2019 From: report at bugs.python.org (Eryk Sun) Date: Mon, 26 Aug 2019 08:16:44 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566807404.22.0.747782694349.issue37945@roundup.psfhosted.org> Eryk Sun added the comment: > But my question is, then: why is my machine failing this test [the > only one which uses this two-part locale] and not the buildbots or > (presumably) any other Windows developer? test_getsetlocale_issue1813 fails for me as well. I can't imagine how setlocale(LC_CTYPE, "tr_TR.ISO8859-9") would succeed with recent versions of the Universal CRT in Windows. It parses "tr_TR" as a BCP 47 locale name, which only supports UTF-8 (e.g. "tr_TR.utf-8") and implicit ANSI (e.g. "tr_TR"). Plus "ISO8859-9" in general isn't a supported encoding of the form ".", ".ACP" (ANSI), ".utf8", or ".utf-8". With the old CRT (2.x and <=3.4) and older versions of the Universal CRT, the initial locale.setlocale(locale.LC_CTYPE 'tr_TR') call fails as an unsupported locale, so the test is skipped: test_getsetlocale_issue1813 (__main__.TestMiscellaneous) ... skipped 'test needs Turkish locale' The old CRT only supports "trk_TUR", "trk_Turkey", "turkish_TUR", and "turkish_Turkey". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 04:34:57 2019 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 26 Aug 2019 08:34:57 +0000 Subject: [issue37948] get_type_hints fails if there are un-annotated fields in a dataclass In-Reply-To: <1566800952.19.0.982220665774.issue37948@roundup.psfhosted.org> Message-ID: <1566808497.3.0.438129301046.issue37948@roundup.psfhosted.org> Change by Eric V. Smith : ---------- assignee: -> eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 04:42:32 2019 From: report at bugs.python.org (Christian Heimes) Date: Mon, 26 Aug 2019 08:42:32 +0000 Subject: [issue37951] Disallow fork in a subinterpreter broke subprocesses in mod_wsgi daemon mode Message-ID: <1566808952.7.0.710040972846.issue37951@roundup.psfhosted.org> New submission from Christian Heimes : BPO https://bugs.python.org/issue34651 disabled fork in subinterpreters. The patch also disabled fork() in _posixsubprocess.fork_exec(). This broke the ability to spawn subprocesses in mod_wsgi daemons, which use subinterpreters. Any attempt to spawn (fork + exec) a subprocess fails with "RuntimeError: fork not supported for subinterpreters": ... File "/usr/lib64/python3.8/subprocess.py", line 829, in __init__ self._execute_child(args, executable, preexec_fn, close_fds, File "/usr/lib64/python3.8/subprocess.py", line 1608, in _execute_child self.pid = _posixsubprocess.fork_exec( RuntimeError: fork not supported for subinterpreters Also see https://bugzilla.redhat.com/show_bug.cgi?id=1745450 ---------- components: Extension Modules, Interpreter Core keywords: 3.8regression messages: 350511 nosy: christian.heimes, eric.snow, vstinner priority: critical severity: normal status: open title: Disallow fork in a subinterpreter broke subprocesses in mod_wsgi daemon mode versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 04:49:04 2019 From: report at bugs.python.org (Christer Weinigel) Date: Mon, 26 Aug 2019 08:49:04 +0000 Subject: [issue37952] Add support for export_keying_material to SSL library Message-ID: <1566809344.46.0.817861457106.issue37952@roundup.psfhosted.org> New submission from Christer Weinigel : Add support for the export_keying_material function to the SSL library. Tested with Python 3.7.4 and Python master branch: https://github.com/wingel/cpython/tree/export_keying_material-3.7.4 https://github.com/wingel/cpython/tree/export_keying_material-master Is this the correct format for a patch? Should I include the automatically generated clinic changes in my patch or not? What about the "versionadded::" string in the documentation? Should I include a line like that or does it only generate unneccessary conflicts? Anything else I need to do? ---------- assignee: christian.heimes components: SSL messages: 350512 nosy: christian.heimes, wingel71 priority: normal severity: normal status: open title: Add support for export_keying_material to SSL library type: enhancement versions: Python 3.7, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 05:16:27 2019 From: report at bugs.python.org (Christian Heimes) Date: Mon, 26 Aug 2019 09:16:27 +0000 Subject: [issue37952] Add support for export_keying_material to SSL library In-Reply-To: <1566809344.46.0.817861457106.issue37952@roundup.psfhosted.org> Message-ID: <1566810987.02.0.475939550882.issue37952@roundup.psfhosted.org> Christian Heimes added the comment: Could you please explain the purpose of the feature and why you want to expose the interface? What's the use case? As this is a new feature, Python 3.7 and 3.8 are out of scope. ---------- versions: -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 05:31:13 2019 From: report at bugs.python.org (Christer Weinigel) Date: Mon, 26 Aug 2019 09:31:13 +0000 Subject: [issue37952] Add support for export_keying_material to SSL library In-Reply-To: <1566809344.46.0.817861457106.issue37952@roundup.psfhosted.org> Message-ID: <1566811873.78.0.886229208412.issue37952@roundup.psfhosted.org> Christer Weinigel added the comment: I'm doing an implementation of the NTS protocol for my customer Netnod: https://github.com/Netnod/nts-poc-python NTS is draft RFC on its way to become a standard: https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ NTS requires the export_keying_material functionality as described in RFC5705. Basically it's a part of the TLS standard, is used by 10 existing protocols with more on the way. And I can't implement a NTS key establishment server or client without the function. That's why I added the functionality and verified that it works both with the stable 3.7.4 release and with the master branch of the cpython repository. I tested with 3.7.4 first on my machine because that's the release of Python that comes with Ubuntu and I wanted to have as few differences as as possible compared to the distribution version. I then forward ported the patch to the master branch and verified that my NTS implementation still works with that branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 05:51:17 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 26 Aug 2019 09:51:17 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566813077.16.0.395481325459.issue34679@roundup.psfhosted.org> Andrew Svetlov added the comment: New changeset 1c0600998681295735a18690fae184b0c9a4ca51 by Andrew Svetlov in branch 'master': bpo-34679: Restore instantiation Windows IOCP event loop from non-main thread (#15492) https://github.com/python/cpython/commit/1c0600998681295735a18690fae184b0c9a4ca51 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 05:52:01 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 09:52:01 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566813121.87.0.91342323199.issue34679@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15198 pull_request: https://github.com/python/cpython/pull/15512 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 05:52:18 2019 From: report at bugs.python.org (Ned Deily) Date: Mon, 26 Aug 2019 09:52:18 +0000 Subject: [issue36344] install_certificates.command too complicated In-Reply-To: <1552911860.35.0.715970160231.issue36344@roundup.psfhosted.org> Message-ID: <1566813138.12.0.487242001149.issue36344@roundup.psfhosted.org> Ned Deily added the comment: So as not to delay 3.8.0b4, I'm removing this as a "release blocker'. Once the implementation is in master, we can consider backporting to other releases. ---------- priority: release blocker -> critical versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 05:53:15 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 26 Aug 2019 09:53:15 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566813195.04.0.189275604216.issue34679@roundup.psfhosted.org> Change by Andrew Svetlov : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 06:04:44 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 26 Aug 2019 10:04:44 +0000 Subject: [issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio In-Reply-To: <1526401266.56.0.682650639539.issue33523@psf.upfronthosting.co.za> Message-ID: <1566813884.86.0.395688676105.issue33523@roundup.psfhosted.org> Andrew Svetlov added the comment: The solution produces subtle and error-prone code. It can live in third party library but not good enough for stdlib I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 06:14:58 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 10:14:58 +0000 Subject: [issue34679] asyncio.add_signal_handler call fails if not on main thread In-Reply-To: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za> Message-ID: <1566814498.33.0.545681824441.issue34679@roundup.psfhosted.org> miss-islington added the comment: New changeset 69d22b8fee442c12829a1032a72489c8133de271 by Miss Islington (bot) in branch '3.8': bpo-34679: Restore instantiation Windows IOCP event loop from non-main thread (GH-15492) https://github.com/python/cpython/commit/69d22b8fee442c12829a1032a72489c8133de271 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 06:24:17 2019 From: report at bugs.python.org (Zackery Spytz) Date: Mon, 26 Aug 2019 10:24:17 +0000 Subject: [issue30076] Opcode names BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL are too long In-Reply-To: <1492277239.5.0.348724747458.issue30076@psf.upfronthosting.co.za> Message-ID: <1566815057.72.0.613297343749.issue30076@roundup.psfhosted.org> Change by Zackery Spytz : ---------- keywords: +patch pull_requests: +15199 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15513 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 06:26:10 2019 From: report at bugs.python.org (Zackery Spytz) Date: Mon, 26 Aug 2019 10:26:10 +0000 Subject: [issue30076] Opcode names BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL are too long In-Reply-To: <1492277239.5.0.348724747458.issue30076@psf.upfronthosting.co.za> Message-ID: <1566815170.81.0.0811789259518.issue30076@roundup.psfhosted.org> Zackery Spytz added the comment: I have created a pull request for this issue. Please take a look. ---------- nosy: +ZackerySpytz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 06:29:36 2019 From: report at bugs.python.org (Zackery Spytz) Date: Mon, 26 Aug 2019 10:29:36 +0000 Subject: [issue27260] Missing equality check for super objects In-Reply-To: <1465332483.31.0.223891907563.issue27260@psf.upfronthosting.co.za> Message-ID: <1566815376.43.0.258214073775.issue27260@roundup.psfhosted.org> Zackery Spytz added the comment: > I don't think this should be done. I agree, and I think this issue should be closed. ---------- nosy: +ZackerySpytz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 06:40:25 2019 From: report at bugs.python.org (Zackery Spytz) Date: Mon, 26 Aug 2019 10:40:25 +0000 Subject: [issue37946] Add the Bessel functions of the first and second kind to the math module In-Reply-To: <1566786579.57.0.437396852549.issue37946@roundup.psfhosted.org> Message-ID: <1566816025.28.0.315195297581.issue37946@roundup.psfhosted.org> Zackery Spytz added the comment: > IMO this is the province of things like scipy.special. The Bessel functions (and many others) are already easily available to users of the scientific Python stack. I don't really see a need to have them in core Python. I agree. ---------- nosy: +ZackerySpytz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 06:46:04 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 10:46:04 +0000 Subject: [issue37951] Disallow fork in a subinterpreter broke subprocesses in mod_wsgi daemon mode In-Reply-To: <1566808952.7.0.710040972846.issue37951@roundup.psfhosted.org> Message-ID: <1566816364.37.0.661223480239.issue37951@roundup.psfhosted.org> STINNER Victor added the comment: subprocess still work in subinterpreters in Python 3.8 if posix_spawn() can be used, but posix_spawn() is only used under some conditions: https://docs.python.org/dev/whatsnew/3.8.html#optimizations "The subprocess module can now use the os.posix_spawn() function in some cases for better performance. Currently, it is only used on macOS and Linux (using glibc 2.24 or newer) if all these conditions are met: * close_fds is false; * preexec_fn, pass_fds, cwd and start_new_session parameters are not set; * the executable path contains a directory." -- It seems like FreeIPA uses ctypes and ctypes calls subprocess.Popen(['/sbin/ldconfig', '-p'], ...) to locale libcrypto. I see different options: * modify FreeIPA / ctypes to ensure that posix_spawn() can be used * avoid subinterpreters to deploy FreeIPA * revert the change to allow again fork in subprocesses: see bpo-34651 for the rationale why it was denied I understand that FreeIPA is run as WSGI using mod_wsgi in Apache. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 06:51:15 2019 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 26 Aug 2019 10:51:15 +0000 Subject: [issue37909] Thread pool return ref hold memory In-Reply-To: <1566420903.63.0.857548145971.issue37909@roundup.psfhosted.org> Message-ID: <1566816675.42.0.668636694944.issue37909@roundup.psfhosted.org> Andrew Svetlov added the comment: In asyncio code please use non-blocking code and await a future returned by run_until_complete. The following code doesn't leak: import asyncio import concurrent import threading def prepare_a_giant_list(): m = [] for i in range(1000*1000): m.append("There's a fat fox jump over a sheep" + str(i)) th_num = threading.active_count() print("Thread number is {}".format(th_num)) return m async def main(): loop = asyncio.get_running_loop() async_executor = concurrent.futures.ThreadPoolExecutor(max_workers=20) await loop.run_in_executor(async_executor, prepare_a_giant_list) await asyncio.sleep(15) await loop.run_in_executor(async_executor, prepare_a_giant_list) await asyncio.sleep(15) await loop.run_in_executor(async_executor, prepare_a_giant_list) await asyncio.sleep(15) await loop.run_in_executor(async_executor, prepare_a_giant_list) await asyncio.sleep(15) if __name__ == "__main__": asyncio.run(main()) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 06:55:24 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 10:55:24 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566816924.89.0.519850572595.issue36205@roundup.psfhosted.org> STINNER Victor added the comment: > process_time: namespace(adjustable=False, implementation='clock_gettime(CLOCK_PROCESS_CPUTIME_ID)', monotonic=True, resolution=1.0000000000000002e-06) Using CLOCK_PROCESS_CPUTIME_ID clock for time.process_time() looks good to me. I don't know why depending on how Python is built, you get a different clock. > process_time: namespace(adjustable=False, implementation='getrusage(RUSAGE_SELF)', monotonic=True, resolution=1e-06) It should be the same clock than CLOCK_PROCESS_CPUTIME_ID, maybe with a different resolution. If both are available, we should prefer the clock with the best *effective* resolution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 07:10:58 2019 From: report at bugs.python.org (Jeroen Demeyer) Date: Mon, 26 Aug 2019 11:10:58 +0000 Subject: [issue37884] Optimize Fraction() and statistics.mean() In-Reply-To: <1566195450.53.0.150552159407.issue37884@roundup.psfhosted.org> Message-ID: <1566817858.01.0.786409702185.issue37884@roundup.psfhosted.org> Jeroen Demeyer added the comment: For the record: making a public math.as_integer_ratio() function was rejected at #37822. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 07:22:16 2019 From: report at bugs.python.org (Christian Heimes) Date: Mon, 26 Aug 2019 11:22:16 +0000 Subject: [issue37951] Disallow fork in a subinterpreter broke subprocesses in mod_wsgi daemon mode In-Reply-To: <1566808952.7.0.710040972846.issue37951@roundup.psfhosted.org> Message-ID: <1566818536.17.0.0640500218508.issue37951@roundup.psfhosted.org> Christian Heimes added the comment: It's a bit more complicated. FreeIPA uses cryptography, which uses asn1crypto, which uses ctypes, which is broken in mod_wsgi due to bpo-34651. It's not just FreeIPA that is affected by the issue. Any application running in mod_wsgi is potentially affected and broken by bpo-34651. 1a) (modify FreeIPA) is not possible. IPA requires the additional features of the subprocess module. 1b) (modify ctypes) should be done in a separate ticket. I'm not sure why subprocess does not use posix_spawn() here. I guess it's the default value "close_fds=True"? 2) (avoid subinterpreters) would require a rewrite of mod_wsgi 3) (revert bpo-34651) is IMHO required for _posixsubprocess.fork_exec(). bpo-34651 is a backwards incompatible change that breaks existing applications that uses mod_wsgi. At least _posixsubprocess.fork_exec() should be reverted and the removal of fork() support should go through a proper deprecation cycle of two releases. I'm bumping this up to release blocker and CC ?ukasz. ---------- nosy: +lukasz.langa priority: critical -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 07:49:12 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Aug 2019 11:49:12 +0000 Subject: [issue36917] ast.NodeVisitor no longer calls visit_Str In-Reply-To: <1557843682.58.0.0807679622364.issue36917@roundup.psfhosted.org> Message-ID: <1566820152.58.0.401026645799.issue36917@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset c2388622923c81b5f06b0c9a5ce821fc03c624b9 by Serhiy Storchaka in branch '3.7': bpo-36917: Backport basic test for ast.NodeVisitor. (GH-15511) https://github.com/python/cpython/commit/c2388622923c81b5f06b0c9a5ce821fc03c624b9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 08:14:21 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Aug 2019 12:14:21 +0000 Subject: [issue36917] ast.NodeVisitor no longer calls visit_Str In-Reply-To: <1557843682.58.0.0807679622364.issue36917@roundup.psfhosted.org> Message-ID: <1566821661.13.0.828783260248.issue36917@roundup.psfhosted.org> Serhiy Storchaka added the comment: Thank you for your report and discussion Anthony. Added the default implementation of visit_Constant which calls corresponding visitor for old constant nodes. It emits a deprecation warning (PendingDeprecationWarning in 3.8 and DeprecationWarning in 3.9) as a reminder that you finally will need to implement your own visit_Constant. You can temporary ignore them. Note that the implementation in the stdlib is not future proof (and it should not, because visit_Constant will likely be removed at the same time or before removing classes Num and Str and removing properties "n" and "s" from Constant). In long term solution you should write something like: class V(ast.NodeVisitor): def _visit_string(self, node, value): ... def visit_Str(self, node): return self._visit_string(node, node.s) def visit_Constant(self, node): if isinstance(node.value, str): return self._visit_string(node, node.value) ... Otherwise you can get other deprecation warnings or errors in future releases. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 08:17:39 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 26 Aug 2019 12:17:39 +0000 Subject: [issue30076] Opcode names BUILD_MAP_UNPACK_WITH_CALL and BUILD_TUPLE_UNPACK_WITH_CALL are too long In-Reply-To: <1492277239.5.0.348724747458.issue30076@psf.upfronthosting.co.za> Message-ID: <1566821859.76.0.501681445636.issue30076@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- versions: +Python 3.9 -Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 08:42:21 2019 From: report at bugs.python.org (Vinay Sharma) Date: Mon, 26 Aug 2019 12:42:21 +0000 Subject: [issue37754] Consistency of Unix's shared_memory implementation with windows In-Reply-To: <1564914758.61.0.506857998168.issue37754@roundup.psfhosted.org> Message-ID: <1566823341.99.0.110300203129.issue37754@roundup.psfhosted.org> Vinay Sharma added the comment: Since, advisory locking doesn't work on integer file descriptors which are returned by shm_open on macos, I was thinking of an alternative way of fixing this. I was thinking of using a shared semaphore, which will store the reference count of the processes using the shared memory segment. resource_tracker will unlink the shared_memory and the shared semaphore, when the count stored by shared semaphore becomes 0. This will ensure that neither the shared memory segment nor the shared semaphore leaks. Does this sound good ? Any suggestions would be very helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 09:58:05 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 13:58:05 +0000 Subject: [issue37946] Add the Bessel functions of the first and second kind to the math module In-Reply-To: <1566786579.57.0.437396852549.issue37946@roundup.psfhosted.org> Message-ID: <1566827885.65.0.818687678738.issue37946@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Thanks for your detailed opinion, Mark. After reflecting on your arguments I agree that we should close this issue as rejected. Thanks to everyone! ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 10:06:04 2019 From: report at bugs.python.org (Dominic Littlewood) Date: Mon, 26 Aug 2019 14:06:04 +0000 Subject: [issue37953] Fix ForwardRef equality checks Message-ID: <1566828364.46.0.753751170409.issue37953@roundup.psfhosted.org> New submission from Dominic Littlewood <11dlittlewood at gmail.com>: Apologies for issuing a pull request without an associated issue. I'm kind of new to this. Nevermind, I'm making one now. The typing module currently contains a bug where ForwardRefs change their hash and equality once they are evaluated. Consider the following code: import typing ref = typing.ForwardRef('MyClass') ref_ = typing.ForwardRef('MyClass') class MyClass: def __add__(self, other: ref): ... # We evaluate one forward reference, but not the other. typing.get_type_hints(MyClass.__add__) # Equality is violated print(ref == ref_) # False # This can cause duplication in Unions. # The following prints: # typing.Union[ForwardRef('MyClass'), ForwardRef('MyClass')] # when it should be: typing.Union[ForwardRef('MyClass')] wrong = typing.Union[ref, ref_] print(wrong) # The union also does not compare equality properly should_be_equal = typing.Union[ref] print(should_be_equal == wrong) # False # In fact this applies to any generic print(typing.Callable[[ref],None] == typing.Callable[[ref_],None]) # False ---------- components: Library (Lib) messages: 350531 nosy: plokmijnuhby priority: normal severity: normal status: open title: Fix ForwardRef equality checks type: behavior versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 10:19:53 2019 From: report at bugs.python.org (SilentGhost) Date: Mon, 26 Aug 2019 14:19:53 +0000 Subject: [issue37953] Fix ForwardRef equality checks In-Reply-To: <1566828364.46.0.753751170409.issue37953@roundup.psfhosted.org> Message-ID: <1566829193.4.0.63073697869.issue37953@roundup.psfhosted.org> Change by SilentGhost : ---------- nosy: +gvanrossum, levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 10:20:34 2019 From: report at bugs.python.org (Sam) Date: Mon, 26 Aug 2019 14:20:34 +0000 Subject: [issue22699] cross-compilation of Python3.4 In-Reply-To: <1413992946.14.0.956103683321.issue22699@psf.upfronthosting.co.za> Message-ID: <1566829234.0.0.614207306878.issue22699@roundup.psfhosted.org> Sam added the comment: Has there been any update on this? I've run into this issue trying to cross-compile python for Android. I've tried 3.7.4, 3.8 and current master, both in-source and out of source builds, all ending with the modules failing to compile due to wrong paths. ... CC='/home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android26-clang' LDSHARED='/home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android26-clang -shared -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libatomic.a -static-libstdc++ -Wl,--build-id -Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack -Wl,--gc-sections -lc++ -lm -lgcc -ldl -lc -lgcc -ldl -latomic -lm -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libatomic.a -static-libstdc++ -Wl,--build-id -Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack -Wl,--gc-sections -lc++ -lm -lgcc -ldl -lc -lgcc -ldl -latomic -lm ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS='' _PYTHON_PROJECT_BASE=/home/samuel/android/cpython _PYTHON_HOST_PLATFORM=linux-aarch64 PYTHONPATH=/home/samuel/android/cpython/build/lib.linux-aarch64-3.7:./Lib _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_m_linux_ python3 ./setup.py build running build running build_ext INFO: Can't locate Tcl/Tk libs and/or headers building '_struct' extension /home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android26-clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall --target=aarch64-none-linux-android26 --gcc-toolchain=/home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64 --sysroot=/home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -fno-addrsig -Wa,--noexecstack -Wformat -Werror=format-security -O3 -fPIE --target=aarch64-none-linux-android26 --gcc-toolchain=/home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64 --sysroot=/home/samuel/android/sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/sysroot -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -fno-addrsig -Wa,--noexecstack -Wformat -Werror=format-security -O3 -fPIE -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -I./Include -I. -I/home/samuel/android/cpython_build/host/venv/include -I/home/samuel/android/cpython_build/host/install/include/python3.7m -c _struct.c -o build/temp.linux-aarch64-3.7/_struct.o clang: error: no such file or directory: '_struct.c' clang: error: no input files ... Failed to build these modules: _asyncio _bisect _blake2 _bz2 _codecs_cn _codecs_hk _codecs_iso2022 _codecs_jp _codecs_kr _codecs_tw _contextvars _crypt _csv _ctypes _ctypes_test _datetime _decimal _heapq _json _lsprof _md5 _multibytecodec _multiprocessing _opcode _pickle _posixsubprocess _queue _random _sha1 _sha256 _sha3 _sha512 _socket _struct _testbuffer _testcapi _testimportmultiple _testmultiphase _uuid _xxtestfuzz array audioop binascii cmath fcntl grp math mmap ossaudiodev parser pyexpat resource select spwd syslog termios unicodedata xxlimited ... ---------- nosy: +iliis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 10:30:13 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 14:30:13 +0000 Subject: [issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots Message-ID: <1566829813.13.0.292904797891.issue37954@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : BUILDBOT FAILURE REPORT ======================= Builder name: AMD64 Windows8.1 Refleaks 3.x Builder url: https://buildbot.python.org/all/#/builders/80/ Build url: https://buildbot.python.org/all/#/builders/80/builds/683 Failed tests ------------ Test leaking resources ---------------------- - test_tools is leaking references - test_exceptions is leaking references - test_compile is leaking references - test_trace is leaking references - test_dis is leaking references - test_builtin is leaking references - test_syntax is leaking references - test_named_expressions is leaking memory blocks - test_syntax is leaking memory blocks - test_symtable is leaking references - test_typing is leaking references - test_future is leaking references - test_global is leaking references - test_opcodes is leaking references - test_grammar is leaking references - test_scope is leaking references - test_named_expressions is leaking references - test_ast is leaking references - test_ast is leaking memory blocks Build summary ------------- == Tests result: FAILURE then FAILURE == 373 tests OK. 10 slowest tests: - test_multiprocessing_spawn: 25 min 17 sec - test_asyncio: 19 min 45 sec - test_mailbox: 15 min 38 sec - test_distutils: 14 min 8 sec - test_concurrent_futures: 13 min 58 sec - test_zipfile: 9 min 36 sec - test_venv: 8 min 8 sec - test_compileall: 6 min 37 sec - test_lib2to3: 6 min 11 sec - test_regrtest: 5 min 43 sec 16 tests failed: test_ast test_builtin test_compile test_dis test_exceptions test_future test_global test_grammar test_named_expressions test_opcodes test_scope test_symtable test_syntax test_tools test_trace test_typing 30 tests skipped: test_curses test_dbm_gnu test_dbm_ndbm test_devpoll test_epoll test_fcntl test_fork1 test_gdb test_grp test_ioctl test_kqueue test_multiprocessing_fork test_multiprocessing_forkserver test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_readline test_resource test_spwd test_syslog test_threadsignals test_wait3 test_wait4 test_xxtestfuzz test_zipfile64 20 re-run tests: test_ast test_asyncgen test_builtin test_compile test_compileall test_dis test_exceptions test_future test_global test_grammar test_named_expressions test_opcodes test_scope test_symtable test_syntax test_tarfile test_threading test_tools test_trace test_typing Total duration: 1 hour 21 min Tracebacks ---------- ```traceback Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\proactor_events.py", line 765, in _loop_self_reading f.result() # may raise File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 808, in _poll value = callback(transferred, key, ov) File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 457, in finish_recv raise ConnectionResetError(*exc.args) ConnectionResetError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request .Cancelling an overlapped future failed future: <_OverlappedFuture pending overlapped= cb=[BaseProactorEventLoop._loop_self_reading()]> Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 66, in _cancel_overlapped self._ov.cancel() OSError: [WinError 6] The handle is invalid Cancelling an overlapped future failed future: <_OverlappedFuture pending overlapped= cb=[BaseProactorEventLoop._loop_self_reading()]> Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 66, in _cancel_overlapped self._ov.cancel() OSError: [WinError 6] The handle is invalid Error on reading from the event loop self pipe loop: Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 453, in finish_recv return ov.getresult() OSError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\proactor_events.py", line 765, in _loop_self_reading f.result() # may raise File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 808, in _poll value = callback(transferred, key, ov) File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 457, in finish_recv raise ConnectionResetError(*exc.args) ConnectionResetError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request .Cancelling an overlapped future failed future: <_OverlappedFuture pending overlapped= cb=[BaseProactorEventLoop._loop_self_reading()]> Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 66, in _cancel_overlapped self._ov.cancel() OSError: [WinError 6] The handle is invalid Cancelling an overlapped future failed future: <_OverlappedFuture pending overlapped= cb=[BaseProactorEventLoop._loop_self_reading()]> Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 66, in _cancel_overlapped self._ov.cancel() OSError: [WinError 6] The handle is invalid Error on reading from the event loop self pipe loop: Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 453, in finish_recv return ov.getresult() OSError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\proactor_events.py", line 765, in _loop_self_reading f.result() # may raise File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 808, in _poll value = callback(transferred, key, ov) File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 457, in finish_recv raise ConnectionResetError(*exc.args) ConnectionResetError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request . Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\proactor_events.py", line 765, in _loop_self_reading f.result() # may raise File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 808, in _poll value = callback(transferred, key, ov) File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 457, in finish_recv raise ConnectionResetError(*exc.args) ConnectionResetError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request .Cancelling an overlapped future failed future: <_OverlappedFuture pending overlapped= cb=[BaseProactorEventLoop._loop_self_reading()]> Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 66, in _cancel_overlapped self._ov.cancel() OSError: [WinError 6] The handle is invalid Cancelling an overlapped future failed future: <_OverlappedFuture pending overlapped= cb=[BaseProactorEventLoop._loop_self_reading()]> Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 66, in _cancel_overlapped self._ov.cancel() OSError: [WinError 6] The handle is invalid Error on reading from the event loop self pipe loop: Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 453, in finish_recv return ov.getresult() OSError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\proactor_events.py", line 765, in _loop_self_reading f.result() # may raise File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 808, in _poll value = callback(transferred, key, ov) File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 457, in finish_recv raise ConnectionResetError(*exc.args) ConnectionResetError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request .Cancelling an overlapped future failed future: <_OverlappedFuture pending overlapped= cb=[BaseProactorEventLoop._loop_self_reading()]> Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 66, in _cancel_overlapped self._ov.cancel() OSError: [WinError 6] The handle is invalid Cancelling an overlapped future failed future: <_OverlappedFuture pending overlapped= cb=[BaseProactorEventLoop._loop_self_reading()]> Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 66, in _cancel_overlapped self._ov.cancel() OSError: [WinError 6] The handle is invalid Error on reading from the event loop self pipe loop: Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 453, in finish_recv return ov.getresult() OSError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 66, in _cancel_overlapped self._ov.cancel() OSError: [WinError 6] The handle is invalid Cancelling an overlapped future failed future: <_OverlappedFuture pending overlapped= cb=[BaseProactorEventLoop._loop_self_reading()]> Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 66, in _cancel_overlapped self._ov.cancel() OSError: [WinError 6] The handle is invalid Error on reading from the event loop self pipe loop: Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 453, in finish_recv return ov.getresult() OSError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\proactor_events.py", line 765, in _loop_self_reading f.result() # may raise File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 808, in _poll value = callback(transferred, key, ov) File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 457, in finish_recv raise ConnectionResetError(*exc.args) ConnectionResetError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request .Cancelling an overlapped future failed future: <_OverlappedFuture pending overlapped= cb=[BaseProactorEventLoop._loop_self_reading()]> Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 66, in _cancel_overlapped self._ov.cancel() OSError: [WinError 6] The handle is invalid Cancelling an overlapped future failed future: <_OverlappedFuture pending overlapped= cb=[BaseProactorEventLoop._loop_self_reading()]> Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 66, in _cancel_overlapped self._ov.cancel() OSError: [WinError 6] The handle is invalid Error on reading from the event loop self pipe loop: Traceback (most recent call last): File "D:\buildarea\3.x.ware-win81-release.refleak\build\lib\asyncio\windows_events.py", line 453, in finish_recv return ov.getresult() OSError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request ``` Current builder status ---------------------- The builder is failing currently Commits ------- Other builds with similar failures ---------------------------------- - https://buildbot.python.org/all/#/builders/1/builds/694 - https://buildbot.python.org/all/#/builders/224/builds/70 - https://buildbot.python.org/all/#/builders/223/builds/84 ---------- messages: 350533 nosy: lukasz.langa, pablogsal priority: release blocker severity: normal status: open title: Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 10:31:40 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 14:31:40 +0000 Subject: [issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots In-Reply-To: <1566829813.13.0.292904797891.issue37954@roundup.psfhosted.org> Message-ID: <1566829900.98.0.763133102415.issue37954@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Bisecting points at commit 5dbe0f59b7a4f39c7c606b48056bc29e406ebf78 as the commit that introduced the reference leaks ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 10:31:59 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 14:31:59 +0000 Subject: [issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots In-Reply-To: <1566829813.13.0.292904797891.issue37954@roundup.psfhosted.org> Message-ID: <1566829919.85.0.916296812379.issue37954@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- keywords: +patch pull_requests: +15200 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15514 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 10:52:46 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 14:52:46 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level In-Reply-To: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> Message-ID: <1566831166.51.0.559977166143.issue37947@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: New changeset 0e4ea16336685cf3fa353d8c54af59b45b2d5c33 by Pablo Galindo in branch 'master': bpo-37947: Adjust correctly the recursion level in symtable for named expressions (GH-15499) https://github.com/python/cpython/commit/0e4ea16336685cf3fa353d8c54af59b45b2d5c33 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 10:56:22 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 14:56:22 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level In-Reply-To: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> Message-ID: <1566831382.88.0.173166769883.issue37947@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- pull_requests: +15202 pull_request: https://github.com/python/cpython/pull/15515 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 10:57:08 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 14:57:08 +0000 Subject: [issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots In-Reply-To: <1566829813.13.0.292904797891.issue37954@roundup.psfhosted.org> Message-ID: <1566831428.06.0.511257339287.issue37954@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: See also https://bugs.python.org/issue37947 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 11:11:48 2019 From: report at bugs.python.org (Paulo Henrique Silva) Date: Mon, 26 Aug 2019 15:11:48 +0000 Subject: [issue37955] mock.patch incorrect reference to Mock Message-ID: <1566832308.08.0.460509709565.issue37955@roundup.psfhosted.org> New submission from Paulo Henrique Silva : When explaining the usage of keyword arguments on mock.patch: ``` patch() takes arbitrary keyword arguments. These will be passed to the Mock (or new_callable) on construction. ``` default new_callable is MagicMock and it should be mentioned here instead of Mock (even tough MagickMock inherits from it). ---------- assignee: docs at python components: Documentation messages: 350537 nosy: docs at python, phsilva priority: normal severity: normal status: open title: mock.patch incorrect reference to Mock versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 11:14:10 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 15:14:10 +0000 Subject: [issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots In-Reply-To: <1566829813.13.0.292904797891.issue37954@roundup.psfhosted.org> Message-ID: <1566832450.35.0.232503477982.issue37954@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: New changeset 4901dc46da5ecb131f8d902a0fbd704934f209e1 by Pablo Galindo in branch 'master': bpo-37954: Fix reference leak in the symtable (GH-15514) https://github.com/python/cpython/commit/4901dc46da5ecb131f8d902a0fbd704934f209e1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 11:14:18 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 15:14:18 +0000 Subject: [issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots In-Reply-To: <1566829813.13.0.292904797891.issue37954@roundup.psfhosted.org> Message-ID: <1566832458.39.0.3956096657.issue37954@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15203 pull_request: https://github.com/python/cpython/pull/15518 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 11:17:16 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 15:17:16 +0000 Subject: [issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots In-Reply-To: <1566829813.13.0.292904797891.issue37954@roundup.psfhosted.org> Message-ID: <1566832636.41.0.498004405262.issue37954@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Scheduled two custom builds of the 3.x refleak buildbots: https://buildbot.python.org/all/#/builders/80/builds/684 https://buildbot.python.org/all/#/builders/1/builds/695 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 11:24:55 2019 From: report at bugs.python.org (Paulo Henrique Silva) Date: Mon, 26 Aug 2019 15:24:55 +0000 Subject: [issue37955] mock.patch incorrect reference to Mock In-Reply-To: <1566832308.08.0.460509709565.issue37955@roundup.psfhosted.org> Message-ID: <1566833095.99.0.798445285033.issue37955@roundup.psfhosted.org> Change by Paulo Henrique Silva : ---------- keywords: +patch pull_requests: +15204 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15521 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 11:27:34 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 15:27:34 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level In-Reply-To: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> Message-ID: <1566833254.49.0.754753931388.issue37947@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: New changeset 3769425abd8da9a59b9645baf90ef49b9c69c140 by Pablo Galindo in branch '3.8': [3.8] bpo-37947: Adjust correctly the recursion level in symtable for named expressions (GH-15499) (GH-15515) https://github.com/python/cpython/commit/3769425abd8da9a59b9645baf90ef49b9c69c140 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 11:28:36 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 15:28:36 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level In-Reply-To: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> Message-ID: <1566833316.29.0.80666255618.issue37947@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 Aug 26 11:29:03 2019 From: report at bugs.python.org (hongweipeng) Date: Mon, 26 Aug 2019 15:29:03 +0000 Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat() In-Reply-To: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org> Message-ID: <1566833343.14.0.0504879220857.issue35829@roundup.psfhosted.org> Change by hongweipeng : ---------- nosy: +hongweipeng _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 11:39:30 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 15:39:30 +0000 Subject: [issue37549] os.dup() fails for standard streams on Windows 7 In-Reply-To: <1562781125.98.0.893970984377.issue37549@roundup.psfhosted.org> Message-ID: <1566833970.59.0.791883758828.issue37549@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 Aug 26 11:44:30 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 15:44:30 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566834270.1.0.865877439995.issue37664@roundup.psfhosted.org> Steve Dower added the comment: Just getting ?ukasz's attention, as this pip release has a critical 3.8 fix for wheel generation (IIUC). Pradyun - just looking for a NEWS file update in your PR to make sure we have the right version numbers listed. ---------- priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 11:49:48 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 15:49:48 +0000 Subject: [issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots In-Reply-To: <1566829813.13.0.292904797891.issue37954@roundup.psfhosted.org> Message-ID: <1566834588.88.0.727833666392.issue37954@roundup.psfhosted.org> miss-islington added the comment: New changeset ed8af33cce5554545d2bd079b23fe551d26fb4bd by Miss Islington (bot) in branch '3.8': bpo-37954: Fix reference leak in the symtable (GH-15514) https://github.com/python/cpython/commit/ed8af33cce5554545d2bd079b23fe551d26fb4bd ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 11:53:15 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 15:53:15 +0000 Subject: [issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots In-Reply-To: <1566829813.13.0.292904797891.issue37954@roundup.psfhosted.org> Message-ID: <1566834795.2.0.252662283201.issue37954@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Scheduled another two custom builds on the 3.8 branch: https://buildbot.python.org/all/#/builders/223/builds/85 https://buildbot.python.org/all/#/builders/224/builds/71 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 12:04:37 2019 From: report at bugs.python.org (Dong-hee Na) Date: Mon, 26 Aug 2019 16:04:37 +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: <1566835477.32.0.466170138252.issue22347@roundup.psfhosted.org> Change by Dong-hee Na : ---------- pull_requests: +15206 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15522 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 12:16:16 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 26 Aug 2019 16:16:16 +0000 Subject: [issue37951] Disallow fork in a subinterpreter broke subprocesses in mod_wsgi daemon mode In-Reply-To: <1566808952.7.0.710040972846.issue37951@roundup.psfhosted.org> Message-ID: <1566836176.4.0.618156596642.issue37951@roundup.psfhosted.org> ?ukasz Langa added the comment: Christian, you're right to treat this as Release Blocker. Let's have this fixed. Assigning Eric? ---------- assignee: -> eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 12:17:57 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 26 Aug 2019 16:17:57 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566836277.48.0.325424428777.issue37664@roundup.psfhosted.org> ?ukasz Langa added the comment: Thanks for looping me in. Waiting for this to be merged. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 12:25:17 2019 From: report at bugs.python.org (mael arnaud) Date: Mon, 26 Aug 2019 16:25:17 +0000 Subject: [issue37956] UUID authorize version 6+ with variant RFC 4122 Message-ID: <1566836717.73.0.582050404986.issue37956@roundup.psfhosted.org> New submission from mael arnaud : The docs stipulates: UUID.version The UUID version number (1 through 5, meaningful only when the variant is RFC_4122). But you can absolutely do: >>> uuid.UUID("25cdb2ef-3764-bb01-9b17-433defc74464") which yields: >>> uuid.UUID("25cdb2ef-3764-bb01-9b17-433defc74464").variant 'specified in RFC 4122' >>> uuid.UUID("25cdb2ef-3764-bb01-9b17-433defc74464").version 11 Since versions above 5 are not defined in the RFC 4122, is it relevant to allow such UUIDs to exist? Every other tool on the internet seem to reject them (but I guess they are regex based). At the very least, maybe the docs should mention something about it, since I'm not sure anyone expects a UUID to be valid and have a version above 5? ---------- components: Library (Lib) messages: 350546 nosy: Erawpalassalg priority: normal severity: normal status: open title: UUID authorize version 6+ with variant RFC 4122 type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 12:30:09 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 16:30:09 +0000 Subject: [issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots In-Reply-To: <1566829813.13.0.292904797891.issue37954@roundup.psfhosted.org> Message-ID: <1566837009.02.0.98348407468.issue37954@roundup.psfhosted.org> Steve Dower added the comment: Great work, Pablo! This does *not* look like it was an easy one to track down. ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 12:33:11 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 16:33:11 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566837191.84.0.598996261447.issue37945@roundup.psfhosted.org> Steve Dower added the comment: So is the fix here to update locale._build_localename to check something like this? if encoding is None: return language elif sys.platform == 'win32' and encoding not in {'utf8', 'utf-8'}: return language else: return language + '.' + encoding ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 13:19:31 2019 From: report at bugs.python.org (Tim Golden) Date: Mon, 26 Aug 2019 17:19:31 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566839971.96.0.0491448353162.issue37945@roundup.psfhosted.org> Tim Golden added the comment: I agree that that could be a fix. And certainly, if it turns out that this could never have (recently) worked as Eryk is suggesting, then let's go for it. But I still have this uneasy feeling that it's not failing on the buildbots and I can't see any sign of a skipped test in the test stdio. I just wonder whether there's something else at play here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 13:28:11 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 26 Aug 2019 17:28:11 +0000 Subject: [issue37951] Disallow fork in a subinterpreter broke subprocesses in mod_wsgi daemon mode In-Reply-To: <1566808952.7.0.710040972846.issue37951@roundup.psfhosted.org> Message-ID: <1566840490.99.0.846479670853.issue37951@roundup.psfhosted.org> Gregory P. Smith added the comment: FWIW, _posixsubprocess.fork_exec() should be safe to allow. The only thing within it to disallow, if you're going to bother to check this at all, is any use of the legacy preexec_fn support. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 13:32:10 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 26 Aug 2019 17:32:10 +0000 Subject: [issue37055] Numerous warnings with blake2 module In-Reply-To: <1558886932.4.0.665756848832.issue37055@roundup.psfhosted.org> Message-ID: <1566840730.69.0.179266918598.issue37055@roundup.psfhosted.org> Gregory P. Smith added the comment: META: Do we still have platforms we support that we do not also require a modern enough OpenSSL version in order for CPython to build that'd provide blake2 for us? I'd love to ditch maintenance of our own copies of the various secure hash function implementations. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 13:48:41 2019 From: report at bugs.python.org (Brett Cannon) Date: Mon, 26 Aug 2019 17:48:41 +0000 Subject: [issue37935] Improve performance of pathlib.scandir() In-Reply-To: <1566628301.14.0.386871182456.issue37935@roundup.psfhosted.org> Message-ID: <1566841721.85.0.432247311342.issue37935@roundup.psfhosted.org> Change by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 13:49:40 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 17:49:40 +0000 Subject: [issue37705] winerror_to_errno implementation In-Reply-To: <1564407660.89.0.454912973453.issue37705@roundup.psfhosted.org> Message-ID: <1566841780.64.0.0793880113786.issue37705@roundup.psfhosted.org> Steve Dower added the comment: While I'm inclined to think it's okay to find the CRT sources (e.g. "C:\Program Files (x86)\Windows Kits\10\Source\10.0.18362.0\ucrt\misc\errno.cpp") and extract the table from there as part of build, the problem I have is that it is woefully incomplete. I'd much rather have a manually managed table. It'd also be nice to expose it through the errno module somehow, probably just as a dict. It also seems like at least some of the WSA* constants (e.g. WSAEBADF==10009) are the equivalent errno plus 10000 (e.g.EBADF==9). Should we be mapping those back to the errno value? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 13:50:12 2019 From: report at bugs.python.org (Brett Cannon) Date: Mon, 26 Aug 2019 17:50:12 +0000 Subject: [issue37936] gitignore file is too broad In-Reply-To: <1566630912.92.0.00349300289224.issue37936@roundup.psfhosted.org> Message-ID: <1566841812.4.0.777407863967.issue37936@roundup.psfhosted.org> Change by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 13:50:51 2019 From: report at bugs.python.org (Christian Heimes) Date: Mon, 26 Aug 2019 17:50:51 +0000 Subject: [issue37055] Numerous warnings with blake2 module In-Reply-To: <1558886932.4.0.665756848832.issue37055@roundup.psfhosted.org> Message-ID: <1566841851.14.0.999893521988.issue37055@roundup.psfhosted.org> Christian Heimes added the comment: Although OpenSSL comes with blake2, it does not support any of the advanced features like keying, personalization, or tree hashing. See https://github.com/openssl/openssl/issues/980 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 13:51:02 2019 From: report at bugs.python.org (Brett Cannon) Date: Mon, 26 Aug 2019 17:51:02 +0000 Subject: [issue37941] python -m and runpy.run_module set different __name__ by default In-Reply-To: <1566669555.03.0.62423685183.issue37941@roundup.psfhosted.org> Message-ID: <1566841862.85.0.152268249366.issue37941@roundup.psfhosted.org> Change by Brett Cannon : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 13:52:39 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 17:52:39 +0000 Subject: [issue37055] Numerous warnings with blake2 module In-Reply-To: <1558886932.4.0.665756848832.issue37055@roundup.psfhosted.org> Message-ID: <1566841959.29.0.169144219019.issue37055@roundup.psfhosted.org> miss-islington added the comment: New changeset b27cbec801e17a13d7fef49116a8fc279930d2b1 by Miss Islington (bot) (Inada Naoki) in branch 'master': bpo-37055: fix warnings in _blake2 module (GH-14646) https://github.com/python/cpython/commit/b27cbec801e17a13d7fef49116a8fc279930d2b1 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 13:52:50 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 17:52:50 +0000 Subject: [issue37055] Numerous warnings with blake2 module In-Reply-To: <1558886932.4.0.665756848832.issue37055@roundup.psfhosted.org> Message-ID: <1566841970.15.0.303053807804.issue37055@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15207 pull_request: https://github.com/python/cpython/pull/15525 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 13:53:04 2019 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 26 Aug 2019 17:53:04 +0000 Subject: [issue37055] Numerous warnings with blake2 module In-Reply-To: <1558886932.4.0.665756848832.issue37055@roundup.psfhosted.org> Message-ID: <1566841984.95.0.884258739219.issue37055@roundup.psfhosted.org> Gregory P. Smith added the comment: oh well, no pony for us this decade. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 14:03:51 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Aug 2019 18:03:51 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566842631.11.0.854719306527.issue37798@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +15208 pull_request: https://github.com/python/cpython/pull/15526 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 14:19:33 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 18:19:33 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566843573.87.0.174457895913.issue37664@roundup.psfhosted.org> miss-islington added the comment: New changeset 10c452b894d95fed06056fe11e8fe8e1a2a60040 by Miss Islington (bot) (Pradyun Gedam) in branch 'master': bpo-37664: Update ensurepip bundled wheels, again (GH-15483) https://github.com/python/cpython/commit/10c452b894d95fed06056fe11e8fe8e1a2a60040 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 14:23:58 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 18:23:58 +0000 Subject: [issue37055] Numerous warnings with blake2 module In-Reply-To: <1558886932.4.0.665756848832.issue37055@roundup.psfhosted.org> Message-ID: <1566843838.78.0.545577082324.issue37055@roundup.psfhosted.org> miss-islington added the comment: New changeset 2bb4fc379b14377e1cdcefad8d5f2fbbb1172524 by Miss Islington (bot) in branch '3.8': bpo-37055: fix warnings in _blake2 module (GH-14646) https://github.com/python/cpython/commit/2bb4fc379b14377e1cdcefad8d5f2fbbb1172524 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 14:26:00 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Aug 2019 18:26:00 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566843960.91.0.0111736313688.issue37798@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 6fee0f8ea72fa68155a32b33b6c0ed9e5a740e45 by Raymond Hettinger in branch 'master': bpo-37798: Minor code formatting and comment clean-ups. (GH-15526) https://github.com/python/cpython/commit/6fee0f8ea72fa68155a32b33b6c0ed9e5a740e45 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 14:26:13 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 18:26:13 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566843973.61.0.978483622693.issue37798@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15209 pull_request: https://github.com/python/cpython/pull/15527 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 14:26:48 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 18:26:48 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566844008.75.0.0474439925517.issue37945@roundup.psfhosted.org> Steve Dower added the comment: I pushed a custom buildbot run that only runs this test in verbose mode, and it looks like the test is being skipped some other way? https://buildbot.python.org/all/#/builders/48/builds/36 https://buildbot.python.org/all/#/builders/42/builds/54 I don't see any evidence there that it's running at all, though I do on my own machine. Perhaps one of the other buildbot settings causes it to run in a different order and something skips the entire class? I haven't dug in enough to figure that out yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 14:27:35 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 18:27:35 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566844055.03.0.580598574789.issue37664@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +15210 pull_request: https://github.com/python/cpython/pull/15528 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 14:27:42 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 18:27:42 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566844062.69.0.744322398949.issue37664@roundup.psfhosted.org> Change by Steve Dower : ---------- pull_requests: +15211 pull_request: https://github.com/python/cpython/pull/15529 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 15:02:59 2019 From: report at bugs.python.org (Arthur Goldberg) Date: Mon, 26 Aug 2019 19:02:59 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1566846179.51.0.101504873101.issue2506@roundup.psfhosted.org> Arthur Goldberg added the comment: Appreciate you working on this Serhiy and Victor! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 15:10:03 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 26 Aug 2019 19:10:03 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566846603.35.0.852906696141.issue37798@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 56c4d2d057de0dcb968148fa1286e587e91f5c91 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-37798: Minor code formatting and comment clean-ups. (GH-15526) (GH-15527) https://github.com/python/cpython/commit/56c4d2d057de0dcb968148fa1286e587e91f5c91 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 15:19:56 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 19:19:56 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566847196.32.0.374130675931.issue37664@roundup.psfhosted.org> miss-islington added the comment: New changeset c1c1a3396391dcc948d332607a0f673e4434da97 by Miss Islington (bot) (Steve Dower) in branch '3.7': [3.7] bpo-37664: Update ensurepip bundled wheels, again (GH-15483) (GH-15529) https://github.com/python/cpython/commit/c1c1a3396391dcc948d332607a0f673e4434da97 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 15:54:53 2019 From: report at bugs.python.org (Christian Heimes) Date: Mon, 26 Aug 2019 19:54:53 +0000 Subject: [issue37055] Numerous warnings with blake2 module In-Reply-To: <1558886932.4.0.665756848832.issue37055@roundup.psfhosted.org> Message-ID: <1566849293.39.0.512807362427.issue37055@roundup.psfhosted.org> Christian Heimes added the comment: I hope that I'll be able to drop our sha3 copy soonish. OpenSSL 1.0.2 reaches EOL by the end of the year. In theory I could require >= 1.1.1 in 3.9... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 15:58:06 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 19:58:06 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566849486.76.0.543842164276.issue37664@roundup.psfhosted.org> Steve Dower added the comment: New changeset 04b750740be6e7c4a7693f1135c4788b40a028c1 by Steve Dower in branch '3.8': bpo-37664: Update ensurepip bundled wheels, again (GH-15483) https://github.com/python/cpython/commit/04b750740be6e7c4a7693f1135c4788b40a028c1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 16:01:25 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 20:01:25 +0000 Subject: [issue37664] Update bundled pip and setuptools In-Reply-To: <1563918687.03.0.591223674737.issue37664@roundup.psfhosted.org> Message-ID: <1566849685.96.0.826038634105.issue37664@roundup.psfhosted.org> Steve Dower added the comment: Going to call this complete now. If there's a reason to take another update before 3.8 releases, we should create a new issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 16:15:50 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Mon, 26 Aug 2019 20:15:50 +0000 Subject: [issue37055] Numerous warnings with blake2 module In-Reply-To: <1558886932.4.0.665756848832.issue37055@roundup.psfhosted.org> Message-ID: <1566850550.51.0.0269405351328.issue37055@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Can we close this issue or remove the release blocker? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 16:24:20 2019 From: report at bugs.python.org (Socob) Date: Mon, 26 Aug 2019 20:24:20 +0000 Subject: [issue25012] pathlib should allow converting to absolute paths without resolving symlinks In-Reply-To: <1441490748.21.0.647656961559.issue25012@psf.upfronthosting.co.za> Message-ID: <1566851060.46.0.619655784065.issue25012@roundup.psfhosted.org> Change by Socob <206a8535 at opayq.com>: ---------- nosy: +Socob _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 16:43:53 2019 From: report at bugs.python.org (Christian Heimes) Date: Mon, 26 Aug 2019 20:43:53 +0000 Subject: [issue37055] Numerous warnings with blake2 module In-Reply-To: <1558886932.4.0.665756848832.issue37055@roundup.psfhosted.org> Message-ID: <1566852233.06.0.900016415495.issue37055@roundup.psfhosted.org> Change by Christian Heimes : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 16:49:43 2019 From: report at bugs.python.org (Vicki Brown) Date: Mon, 26 Aug 2019 20:49:43 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1566852583.58.0.852592338962.issue24313@roundup.psfhosted.org> Vicki Brown added the comment: This is still broken. With pandas being popular, it's more likely someone might hit it. Can we fix this? At the very least, the error message needs to be made much more specific. I have created a dictionary containing pandas stats. ``` def summary_stats(s): """ Calculate summary statistics for a series or list, s returns a dictionary """ stats = { 'count': 0, 'max': 0, 'min': 0, 'mean': 0, 'median': 0, 'mode': 0, 'std': 0, 'z': (0,0) } stats['count'] = s.count() stats['max'] = s.max() stats['min'] = s.min() stats['mean'] = round(s.mean(),3) stats['median'] = s.median() stats['mode'] = s.mode()[0] stats['std'] = round(s.std(),3) std3 = 3* stats['std'] low_z = round(stats['mean'] - (std3),3) high_z = round(stats['mean'] + (std3),3) stats['z'] = (low_z, high_z) return(stats) ``` Apparently, pandas (sometimes) returns numpy ints and numpy floats. Here's a piece of the dictionary: ``` {'count': 597, 'max': 0.95, 'min': 0.01, 'mean': 0.585, 'median': 0.58, 'mode': 0.59, 'std': 0.122, 'z': (0.219, 0.951)} ```` It looks fine, but when I try to dump the dict to json ``` with open('Data/station_stats.json', 'w') as fp: json.dump(station_stats, fp) ``` I get this error ``` TypeError: Object of type int64 is not JSON serializable ``` **Much searching** led me to discover that I apparently have numpy ints which I have confirmed. ``` for key, value in station_stats['657']['Fluorescence'].items(): print(key, value, type(value)) count 3183 max 2.8 min 0.02 mean 0.323 median 0.28 mode 0.24 std 0.194 z (-0.259, 0.905) ``` ``` #### Problem description pandas statistics sometimes produce numpy numerics. numpy ints are not supported by json.dump #### Expected Output I expect ints, floats, strings, ... to be JSON srializable.
INSTALLED VERSIONS ------------------ commit : None python : 3.7.3.final.0 python-bits : 64 OS : Darwin OS-release : 15.6.0 machine : x86_64 processor : i386 byteorder : little LC_ALL : None LANG : en_US.UTF-8 LOCALE : en_US.UTF-8 pandas : 0.25.0 numpy : 1.16.4 pytz : 2019.1 dateutil : 2.8.0 pip : 19.1.1 setuptools : 41.0.1 Cython : 0.29.12 pytest : 5.0.1 hypothesis : None sphinx : 2.1.2 blosc : None feather : None xlsxwriter : 1.1.8 lxml.etree : 4.3.4 html5lib : 1.0.1 pymysql : 0.9.3 psycopg2 : None jinja2 : 2.10.1 IPython : 7.7.0 pandas_datareader: None bs4 : 4.7.1 bottleneck : 1.2.1 fastparquet : None gcsfs : None lxml.etree : 4.3.4 matplotlib : 3.1.0 numexpr : 2.6.9 odfpy : None openpyxl : 2.6.2 pandas_gbq : None pyarrow : None pytables : None s3fs : None scipy : 1.3.0 sqlalchemy : 1.3.5 tables : 3.5.2 xarray : None xlrd : 1.2.0 xlwt : 1.3.0 xlsxwriter : 1.1.8
---------- nosy: +vlbrown type: enhancement -> behavior versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 16:51:32 2019 From: report at bugs.python.org (Eryk Sun) Date: Mon, 26 Aug 2019 20:51:32 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566852692.73.0.80295634648.issue37945@roundup.psfhosted.org> Eryk Sun added the comment: We get into trouble with test_getsetlocale_issue1813 because normalize() maps "tr_TR" (supported) to "tr_TR.ISO8859-9" (not supported). >>> locale.normalize('tr_TR') 'tr_TR.ISO8859-9' We should skip normalize() in Windows. It's based on a POSIX locale_alias mapping that can only cause problems. The work for normalizing locale names in Windows is best handled inline in _build_localename and _parse_localename. For the old long form, C setlocale always returns the codepage encoding (e.g. "Turkish_Turkey.1254") or "utf8", so that's simple to parse. For BCP 47 locales, the encoding is either "utf8" or "utf-8", or nothing at all. For the latter, there's an implied legacy ANSI encoding. This is used by the CRT wherever we depend on byte strings, such as in time.strftime: mojibake: >>> locale.setlocale(locale.LC_CTYPE, 'en_GB') 'en_GB' >>> time.strftime("\u0100") 'A' correct: >>> locale.setlocale(locale.LC_CTYPE, 'en_GB.utf-8') 'en_GB.utf-8' >>> time.strftime("\u0100") '?' (We should switch back to using wcsftime if possible.) The implicit BCP-47 case can be parsed as `None` -- e.g. ("tr_TR", None). However, it might be useful to support getting the ANSI codepage via GetLocaleInfoEx [1]. A high-level function in locale could internally call _locale.getlocaleinfo(locale_name, LOCALE_IDEFAULTANSICODEPAGE). This would return a string such as "1254". or "0" for a Unicode-only language. For _build_localename, we can't simply limit the encoding to UTF-8. We need to support the old long/abbreviated forms (e.g. "trk_TUR", "turkish_Turkey") in addition to the newer BCP 47 locale names. In the old form we have to support the following encodings: * codepage encodings, with an optional "cp" prefix that has to be stripped, e.g. ("trk_TUR", "cp1254") -> "trk_TUR.1254" * "ACP" in upper case only -- for the ANSI codepage of the language * "utf8" (mixed case) and "utf-8" (mixed case) (The CRT documentation says "OEM" should also be supported, but it's not.) A locale name can also omit the language in the old form -- e.g. (None, "ACP") or (None, "cp1254"). The CRT uses the current language in this case. This is discouraged because the result may be nonsense. [1] https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getlocaleinfoex ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 17:23:53 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 21:23:53 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566854633.61.0.267732314991.issue37945@roundup.psfhosted.org> Steve Dower added the comment: Oh yeah, that locale_alias table is useless on Windows :( But at least the function is documented in such a way that we can change it: "The returned locale code is formatted for use with :func:`setlocale`." Alternatively, we could make setlocale() do its own normalization step on Windows and ignore (or otherwise validate/reject) the encoding. None of that explains why the test doesn't seem to run at all on the buildbots though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 17:31:51 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 21:31:51 +0000 Subject: [issue24479] Support LMMS project files in mimetypes.guess_type In-Reply-To: <1434795502.53.0.948243693094.issue24479@psf.upfronthosting.co.za> Message-ID: <1566855111.47.0.687932191912.issue24479@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: -vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 17:32:02 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 21:32:02 +0000 Subject: [issue24479] Support LMMS project files in mimetypes.guess_type In-Reply-To: <1434795502.53.0.948243693094.issue24479@psf.upfronthosting.co.za> Message-ID: <1566855122.66.0.357143385655.issue24479@roundup.psfhosted.org> Change by STINNER Victor : ---------- keywords: -easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 17:35:12 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 21:35:12 +0000 Subject: [issue30162] Add _PyTuple_Empty and make PyTuple_New(0) never failing In-Reply-To: <1493139112.34.0.200828606997.issue30162@psf.upfronthosting.co.za> Message-ID: <1566855312.28.0.135462323992.issue30162@roundup.psfhosted.org> STINNER Victor added the comment: We could add a _PyTuple_Init() function to ensure that the empty tuple singleton is created as soon as possible, as call it early, in pycore_init_types(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 17:43:13 2019 From: report at bugs.python.org (Eryk Sun) Date: Mon, 26 Aug 2019 21:43:13 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566855793.96.0.342723216844.issue37945@roundup.psfhosted.org> Eryk Sun added the comment: > None of that explains why the test doesn't seem to run at all on the > buildbots though. Are the buildbots using an older version of UCRT? BCP 47 locales used to strictly require a hyphen as the delimiter (e.g. 'tr-TR') instead of underscore (e.g. 'tr_TR'). Supporting underscore and UTF-8 are relatively recent additions that aren't documented yet. Even WINAPI GetLocaleInfoEx supports underscore as the delimiter now, which is also undocumented behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 17:45:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 21:45:39 +0000 Subject: [issue37925] --embed not included in python3.8-config usage/--help In-Reply-To: <1566539578.53.0.511767507414.issue37925@roundup.psfhosted.org> Message-ID: <1566855939.84.0.727510433265.issue37925@roundup.psfhosted.org> STINNER Victor added the comment: New changeset d3cc189b17c86f670198aca109b5ffa2d526d87a by Victor Stinner (Batuhan Ta?kaya) in branch 'master': bpo-37925: Mention --embed in python-config usage (GH-15458) https://github.com/python/cpython/commit/d3cc189b17c86f670198aca109b5ffa2d526d87a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 17:45:48 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 21:45:48 +0000 Subject: [issue37925] --embed not included in python3.8-config usage/--help In-Reply-To: <1566539578.53.0.511767507414.issue37925@roundup.psfhosted.org> Message-ID: <1566855948.14.0.0433628740668.issue37925@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15212 pull_request: https://github.com/python/cpython/pull/15530 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 17:46:48 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 21:46:48 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566856008.91.0.675170479047.issue37945@roundup.psfhosted.org> Steve Dower added the comment: > test_getsetlocale_issue1813 (test.test_locale.TestMiscellaneous) ... skipped 'test needs Turkish locale' Yeah, looks like they're failing that part of the test. I'll run them again with the hyphen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 17:51:59 2019 From: report at bugs.python.org (Steve Dower) Date: Mon, 26 Aug 2019 21:51:59 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566856319.81.0.453288984864.issue37945@roundup.psfhosted.org> Steve Dower added the comment: Oh man, this is too broken for me to think about today... If someone feels like writing a Windows-specific normalize() function to totally replace the Unix one, feel free, but it looks like we won't be able to get away with anything less. The "easy" change breaks a variety of other tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 17:55:34 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 21:55:34 +0000 Subject: [issue37925] --embed not included in python3.8-config usage/--help In-Reply-To: <1566539578.53.0.511767507414.issue37925@roundup.psfhosted.org> Message-ID: <1566856534.87.0.0145544191189.issue37925@roundup.psfhosted.org> miss-islington added the comment: New changeset b8a22ac856944d1dded46ed4caa795e07bfaf0c6 by Miss Islington (bot) in branch '3.8': bpo-37925: Mention --embed in python-config usage (GH-15458) https://github.com/python/cpython/commit/b8a22ac856944d1dded46ed4caa795e07bfaf0c6 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 17:56:43 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 21:56:43 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566856603.65.0.551645527519.issue36763@roundup.psfhosted.org> Change by STINNER Victor : ---------- pull_requests: +15213 pull_request: https://github.com/python/cpython/pull/15532 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 17:57:45 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 21:57:45 +0000 Subject: [issue2506] Add mechanism to disable optimizations In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za> Message-ID: <1566856665.22.0.0380292088788.issue2506@roundup.psfhosted.org> STINNER Victor added the comment: > There are different optimizations on different levels (AST, bytecode generation, peepholer), would be nice to control them separately. This means that we should pass a bitset to the compiler. What's the use case for enabling some AST optimizations but disable bytecode generation optimizations? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 18:05:01 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 22:05:01 +0000 Subject: [issue13341] Incorrect documentation for "u" PyArg_Parse format unit In-Reply-To: <1320412814.48.0.657162308895.issue13341@psf.upfronthosting.co.za> Message-ID: <1566857101.72.0.711636586521.issue13341@roundup.psfhosted.org> STINNER Victor added the comment: I don't think that it's still worth it to update Python 2 documentation at this point. I suggest to focus on enhancement of the Python 3 documentation instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 18:13:36 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 22:13:36 +0000 Subject: [issue37531] Fix regrtest timeout for subprocesses: regrtest -jN --timeout=SECONDS In-Reply-To: <1562700862.92.0.104600612678.issue37531@roundup.psfhosted.org> Message-ID: <1566857616.57.0.100922385615.issue37531@roundup.psfhosted.org> STINNER Victor added the comment: Eryk Sun > Alternatively, instead of special casing the file type and spinning on PeekNamedPipe, the workaround could be based on a multiple-object wait that includes the child process handle. (...) Well, maybe we could do something to enhance regrtest, but the initial bug described in this issue should be fixed by my commit de2d9eed8bc628533e1628b843cc4c7a5010f6e5 which added a timeout to the second Popen.communicate() call, but also to the Popen.wait() call (moreover, "with popen:" is no longer used). Both functions use a timeout of 30 seconds which should be short enough to prevent the main regrtest process to block for hours. When a process is killed and stdout.read() never completes, the stdout.read() thread will likely never completes. But I consider that it's a separated bug that should be addressed in a separated issue. Jeremy Kloth: > In short, the PR doesn't change the problem. The regrtest main will wait indefinitely on the successfully killed process. Again, my commit de2d9eed8bc628533e1628b843cc4c7a5010f6e5 should fix this behavior. -- I'm not sure why test_regrtest.test_multiprocessing_timeout() failed with a timeout on x86 Windows7 3.x; see msg350060. Maybe my commit 767434c39c8f3c6a8af1b3282d8382ccf809fe21 will give more information if the test fails again on this buildbot. I will backport regrtest changes to other 3.7 and 3.8 branches. I wait a few more days to see if buildbots are stable with latest regrtest changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 18:23:04 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 22:23:04 +0000 Subject: [issue37925] --embed not included in python3.8-config usage/--help In-Reply-To: <1566539578.53.0.511767507414.issue37925@roundup.psfhosted.org> Message-ID: <1566858184.53.0.97059346955.issue37925@roundup.psfhosted.org> STINNER Victor added the comment: Thanks Batuhan Ta?kaya for the fix, and thanks Miro Hron?ok for the bug report! Note: --embed was already mentioned in python-config.py usage help. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 18:45:48 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 22:45:48 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566859548.23.0.0880478134871.issue36763@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 9a943b4ce13fac26873b8100e89c818c5c47ac4b by Victor Stinner in branch 'master': bpo-36763: Make Py_BytesMain() public (GH-15532) https://github.com/python/cpython/commit/9a943b4ce13fac26873b8100e89c818c5c47ac4b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 18:45:55 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 22:45:55 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566859555.79.0.662828071467.issue36763@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15214 pull_request: https://github.com/python/cpython/pull/15535 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 18:51:01 2019 From: report at bugs.python.org (Vicki Brown) Date: Mon, 26 Aug 2019 22:51:01 +0000 Subject: [issue24313] json fails to serialise numpy.int64 In-Reply-To: <1432801951.51.0.0124262456045.issue24313@psf.upfronthosting.co.za> Message-ID: <1566859861.67.0.943342058398.issue24313@roundup.psfhosted.org> Vicki Brown added the comment: Note also that pandas DataFrame.to_json() method has no issue with int64. Perhaps you could borrow their code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 19:01:41 2019 From: report at bugs.python.org (STINNER Victor) Date: Mon, 26 Aug 2019 23:01:41 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566860501.78.0.115444329115.issue36763@roundup.psfhosted.org> STINNER Victor added the comment: I marked the PEP 587 Status as Final. The implementation should now be complete. If there are bugs, they can be fixed in following issues :-) I close now this issue. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 19:17:59 2019 From: report at bugs.python.org (miss-islington) Date: Mon, 26 Aug 2019 23:17:59 +0000 Subject: [issue36763] Implementation of the PEP 587 In-Reply-To: <1556663939.96.0.509924822981.issue36763@roundup.psfhosted.org> Message-ID: <1566861479.63.0.129922952689.issue36763@roundup.psfhosted.org> miss-islington added the comment: New changeset 1d4285a042772c7a31c4e19f8dbcbcf9b2ee3b95 by Miss Islington (bot) in branch '3.8': bpo-36763: Make Py_BytesMain() public (GH-15532) https://github.com/python/cpython/commit/1d4285a042772c7a31c4e19f8dbcbcf9b2ee3b95 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 20:03:54 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 27 Aug 2019 00:03:54 +0000 Subject: [issue37957] Allow regrtest to receive a file with test (and subtests) to ignore Message-ID: <1566864234.54.0.166621143796.issue37957@roundup.psfhosted.org> New submission from Pablo Galindo Salgado : When building Python in some uncommon platforms (I am looking at you Solaris and AIX) there are some known tests that will fail. Right now, regrtest has the ability to ignore entire tests using the -x option and to receive a filter file using the --matchfile filter. The problem with the --matchfile option is that it receives a file with patterns to accept and when you want to ignore a couple of tests and subtests, is too cumbersome to lists ALL tests that are not the ones that you want to accept. The problem with -x is that is not easy to ignore just a subtests that fail and the whole tests needs to be ignored. So I suggest to add a new command line option similar to --matchfile but the other way around. Another possibility is allowing to reverse the meaning of the matchfile argument, but I find that a bit more confusing. ---------- components: Tests messages: 350584 nosy: pablogsal, vstinner priority: normal severity: normal status: open title: Allow regrtest to receive a file with test (and subtests) to ignore type: enhancement versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 20:48:33 2019 From: report at bugs.python.org (Eryk Sun) Date: Tue, 27 Aug 2019 00:48:33 +0000 Subject: [issue37705] winerror_to_errno implementation In-Reply-To: <1564407660.89.0.454912973453.issue37705@roundup.psfhosted.org> Message-ID: <1566866913.76.0.259737803786.issue37705@roundup.psfhosted.org> Eryk Sun added the comment: > It also seems like at least some of the WSA* constants (e.g. > WSAEBADF==10009) are the equivalent errno plus 10000 > (e.g.EBADF==9). Should we be mapping those back to the > errno value? Mapping WSAEINTR (10004) -> EINTR (4) and WSAEACCES (10013) -> EACCES (13) would allow special casing them as InterruptedError and PermissionError. This is different from the aliases such as EWOULDBLOCK = WSAEWOULDBLOCK, but it should be fine since the six affected values are singled out in WinSock2.h as C errno values. So the Winsock section becomes a switch: /* Winsock error codes (10000-11999) are errno values. */ if (winerror >= 10000 && winerror < 12000) { switch(winerror) { case WSAEINTR: case WSAEBADF: case WSAEACCES: case WSAEFAULT: case WSAEINVAL: case WSAEMFILE: /* Winsock definitions of errno values. See WinSock2.h */ return winerror - 10000; default: return winerror; } } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 21:01:16 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 Aug 2019 01:01:16 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566867676.38.0.0579794730612.issue36205@roundup.psfhosted.org> Raymond Hettinger added the comment: I'm unclear on why our production release being built on macoS 10.11.x+ or earlier and why it using Clang 6.0 (clang-600.0.57). For me, Python builds fine (and does have this issue) on Mojave 10.14.6 using Clang 10.0.1 (clang-1001.0.46.4). ISTM that using the latest tooling would solve this bug right quick (at least for the current 3.8 release) and would likely generate better code (presumably there have been bug fixes and optimizations between Clang 6.0 and Clang 10.0). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 21:16:36 2019 From: report at bugs.python.org (Ashwin Ramaswami) Date: Tue, 27 Aug 2019 01:16:36 +0000 Subject: [issue34276] urllib.parse doesn't round-trip file URI's with multiple leading slashes In-Reply-To: <1532925543.25.0.56676864532.issue34276@psf.upfronthosting.co.za> Message-ID: <1566868596.92.0.735638755982.issue34276@roundup.psfhosted.org> Change by Ashwin Ramaswami : ---------- versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 22:48:09 2019 From: report at bugs.python.org (Inada Naoki) Date: Tue, 27 Aug 2019 02:48:09 +0000 Subject: [issue37328] remove deprecated HTMLParser.unescape In-Reply-To: <1560839410.8.0.633433607628.issue37328@roundup.psfhosted.org> Message-ID: <1566874089.73.0.596295728566.issue37328@roundup.psfhosted.org> Inada Naoki added the comment: New changeset fae0ed5099de594a9204071d555cb8b76368cbf4 by Inada Naoki in branch 'master': bpo-37328: remove deprecated HTMLParser.unescape (GH-14186) https://github.com/python/cpython/commit/fae0ed5099de594a9204071d555cb8b76368cbf4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 22:48:30 2019 From: report at bugs.python.org (Inada Naoki) Date: Tue, 27 Aug 2019 02:48:30 +0000 Subject: [issue37328] remove deprecated HTMLParser.unescape In-Reply-To: <1560839410.8.0.633433607628.issue37328@roundup.psfhosted.org> Message-ID: <1566874110.53.0.138229321314.issue37328@roundup.psfhosted.org> Change by Inada Naoki : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 23:22:51 2019 From: report at bugs.python.org (Rajiv Vijayakumar) Date: Tue, 27 Aug 2019 03:22:51 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566876171.92.0.167755309143.issue36205@roundup.psfhosted.org> Change by Rajiv Vijayakumar : ---------- pull_requests: +15215 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15538 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 23:27:33 2019 From: report at bugs.python.org (Rajiv Vijayakumar) Date: Tue, 27 Aug 2019 03:27:33 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566876453.19.0.959209707045.issue36205@roundup.psfhosted.org> Rajiv Vijayakumar added the comment: I think I have found the root cause - there appears to be a typo in the rusage implementation - instead of computing the total time as utime+stime, the code performs utime+utime, which explains the doubling observed. I have create a PR with the fix. My Mac runs Mojave with Clang 10.0.1, so I haven't actually been able to test the rusage path yet to make absolutely sure that the patch does the right thing. ---------- nosy: +rvijayak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 23:45:28 2019 From: report at bugs.python.org (hongweipeng) Date: Tue, 27 Aug 2019 03:45:28 +0000 Subject: [issue37935] Improve performance of pathlib.scandir() In-Reply-To: <1566628301.14.0.386871182456.issue37935@roundup.psfhosted.org> Message-ID: <1566877528.39.0.644768307095.issue37935@roundup.psfhosted.org> hongweipeng added the comment: Scandir() will be close when it iteration is over.You can see ScandirIterator_iternext: ``` static PyObject * ScandirIterator_iternext(ScandirIterator *iterator) { while (1) { ... } /* Error or no more files */ ScandirIterator_closedir(iterator); return NULL; } ``` So, `entries = list(scandir(parent_path))` resources in this code can be properly closed. ---------- nosy: +hongweipeng _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 23:52:45 2019 From: report at bugs.python.org (Ned Deily) Date: Tue, 27 Aug 2019 03:52:45 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566877965.66.0.0720082829293.issue36205@roundup.psfhosted.org> Ned Deily added the comment: Thanks, Rajiv, your diagnosis and fix in PR 15538 is indeed correct. ---------- assignee: vstinner -> ned.deily stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Aug 26 23:52:58 2019 From: report at bugs.python.org (Daniel Olshansky) Date: Tue, 27 Aug 2019 03:52:58 +0000 Subject: [issue37958] Adding get_profile_dict to pstats Message-ID: <1566877978.54.0.497370622216.issue37958@roundup.psfhosted.org> New submission from Daniel Olshansky : pstats is really useful or profiling and printing the output of the execution of some block of code, but I've found on multiple occasions that sometimes I'd like to access this output directly in an easily usable dictionary on which I can further analyze or manipulate. My proposal is to add a function called get_profile_dict inside of pstats that'll automatically return this data. Please note that the PR I've put up is just a first version to get some feedback on, and it needs to be updated if the community chooses to move forward with it (e.g. we shouldn't be calling get_print_list inside of get_profile_dict in production code). ---------- components: Extension Modules messages: 350591 nosy: Daniel Olshansky, pablogsal priority: normal pull_requests: 15216 severity: normal status: open title: Adding get_profile_dict to pstats type: enhancement versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 00:06:44 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 Aug 2019 04:06:44 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566878804.21.0.862526079156.issue36205@roundup.psfhosted.org> Raymond Hettinger added the comment: Looks like the regression happened 2017-11-02 in commit c29b585fd4b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 00:13:16 2019 From: report at bugs.python.org (Ned Deily) Date: Tue, 27 Aug 2019 04:13:16 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566879196.94.0.940949500141.issue36205@roundup.psfhosted.org> Ned Deily added the comment: New changeset 8bf5fef8737fdd12724b9340d76a4ed391c4ad8a by Ned Deily (vrajivk) in branch 'master': bpo-36205: Fix the rusage implementation of time.process_time() (GH-15538) https://github.com/python/cpython/commit/8bf5fef8737fdd12724b9340d76a4ed391c4ad8a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 00:13:24 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 27 Aug 2019 04:13:24 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566879204.57.0.670139710379.issue36205@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15217 stage: commit review -> patch review pull_request: https://github.com/python/cpython/pull/15539 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 00:13:30 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 27 Aug 2019 04:13:30 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566879210.92.0.191952266467.issue36205@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15218 pull_request: https://github.com/python/cpython/pull/15540 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 00:31:30 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 27 Aug 2019 04:31:30 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566880290.57.0.195032347421.issue36205@roundup.psfhosted.org> miss-islington added the comment: New changeset 1bf672f53a83c471e6fc4599d2d5149fd6842ff2 by Miss Islington (bot) in branch '3.7': bpo-36205: Fix the rusage implementation of time.process_time() (GH-15538) https://github.com/python/cpython/commit/1bf672f53a83c471e6fc4599d2d5149fd6842ff2 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 00:32:08 2019 From: report at bugs.python.org (Jason Fried) Date: Tue, 27 Aug 2019 04:32:08 +0000 Subject: [issue33523] loop.run_until_complete re-entrancy to support more complicated codebases in transition to asyncio In-Reply-To: <1566813884.86.0.395688676105.issue33523@roundup.psfhosted.org> Message-ID: Jason Fried added the comment: Yeah I have to agree at this point, from a naive point of view it looks awesome, but its just as bad as loosing gil guarantees. On Mon, Aug 26, 2019 at 03:04 Andrew Svetlov wrote: > > Andrew Svetlov added the comment: > > The solution produces subtle and error-prone code. It can live in third > party library but not good enough for stdlib I think. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 00:34:35 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 27 Aug 2019 04:34:35 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566880475.29.0.0700083207958.issue36205@roundup.psfhosted.org> miss-islington added the comment: New changeset 91020fade6ca0f22eef2d338be1380b17385e715 by Miss Islington (bot) in branch '3.8': bpo-36205: Fix the rusage implementation of time.process_time() (GH-15538) https://github.com/python/cpython/commit/91020fade6ca0f22eef2d338be1380b17385e715 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 00:40:50 2019 From: report at bugs.python.org (Ned Deily) Date: Tue, 27 Aug 2019 04:40:50 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566880850.52.0.0431814311272.issue36205@roundup.psfhosted.org> Ned Deily added the comment: Thanks once again, Rajiv! Fix merged for release in 3.8.0b4 and 3.7.5. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 00:59:23 2019 From: report at bugs.python.org (Tim Golden) Date: Tue, 27 Aug 2019 04:59:23 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1566881963.17.0.730739350871.issue37945@roundup.psfhosted.org> Tim Golden added the comment: This feels like one of those changes where what's in place is clearly flawed but any change seems like it'll break stuff which people have had in place for years. I'll try to look at a least-breaking change but I'm honestly not sure what that would look like. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 01:02:12 2019 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 27 Aug 2019 05:02:12 +0000 Subject: [issue37827] IDLE Shell: add a terminal mode that responds to \a, \b, and \r In-Reply-To: <1565592773.8.0.657523892243.issue37827@roundup.psfhosted.org> Message-ID: <1566882132.43.0.279468580811.issue37827@roundup.psfhosted.org> Terry J. Reedy added the comment: In this post, I slightly expand the terminal mode proposal and define the context in which I will accept it. The context will be the subject of other issues. In the next post (tomorrow) I will try to define a reviewable specification for the terminal mode. --- The proposal that IDLE's should *always* respond to \b and \r "properly , like terminals" is the combined proposal of #24572 and the original proposal of #23220. The combined proposal was rejected in the latter, for reasons best given by Serhiy in msg246602. More is given below. #23220 was then redefined as a doc issue. I noted in #23220 that one solution for people who wanted terminal-like behavior would be to add an option to execute code being edited to the system terminal. However, this a) throws away the benefits of running in Shell and b) would not apply to interactive exploration. While running in a terminal is needed for certain use cases, it is not needed for handling control of line output. What Shell should do with control characters in output depends on the users goal. I propose that Shell should have 3 display modes that treat ascii control codes differently for different use cases. 1) Raw mode (the current mode). IDLE inserts all BMP chars into the tk Text. This is needed if one is using a font that has glyphs associated with control codes. On Windows 10, the 8514oem font (the MSDOS font) has symbols for all control codes except NUL and newline. This is a rare need; this mode should not be the default. 2) Development mode (my proposed new default). To the extent possible, developers should be able to see the characters their program produces without adding repr() to all their print and write statements (and later deleting them). Control chars would be replaced with unique glyphs, such as 'Control Pictures', \u2400-\u241f, ? ? ? ? ? ? ? ? ????????? ? ? ? ? ? ? ? ? ? ? ? ? ? ?. or maybe circled letters, \u24d0-\u24df,\u24b6-\u24c5, ?-?, ?-?. Replacements would be tagged as such and get distinct highlight colors. The purpose of a visible tag is to differentiate replacements from characters actually output by the users program. To fulfill the goal of Development mode, more is needed. Astral chars, instead of causing an exception, should be replaced by a string consisting of their \U escape and tagged as a replacement. This is needed anywhere astral chars can appear. It would also be nice to get the codepoint and name of any displayed character. If implemented, this should be added to the base editor class. 3) Terminal mode. Tk interprets \n and \t. Also interpret (to begin with) \a, \b, and \r. The motivation for the latter two has already been given. As said above, the specification is deferred to another post. ---------- title: IDLE: Have the shell mimic terminal handling of \r and \b control characters in outputs -> IDLE Shell: add a terminal mode that responds to \a, \b, and \r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 01:12:13 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 27 Aug 2019 05:12:13 +0000 Subject: [issue37949] Create empty __annotations__ dictionaries lazily In-Reply-To: <1566801588.69.0.745320126697.issue37949@roundup.psfhosted.org> Message-ID: <1566882733.52.0.0455135934495.issue37949@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 01:34:27 2019 From: report at bugs.python.org (Greg Price) Date: Tue, 27 Aug 2019 05:34:27 +0000 Subject: [issue37936] gitignore file is too broad In-Reply-To: <1566630912.92.0.00349300289224.issue37936@roundup.psfhosted.org> Message-ID: <1566884067.96.0.183404484523.issue37936@roundup.psfhosted.org> Change by Greg Price : ---------- pull_requests: +15219 pull_request: https://github.com/python/cpython/pull/15542 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 01:40:04 2019 From: report at bugs.python.org (Greg Price) Date: Tue, 27 Aug 2019 05:40:04 +0000 Subject: [issue37936] gitignore file is too broad In-Reply-To: <1566630912.92.0.00349300289224.issue37936@roundup.psfhosted.org> Message-ID: <1566884404.12.0.409328462421.issue37936@roundup.psfhosted.org> Greg Price added the comment: > I have a minimal fix which takes care of all the files above. I'll post that shortly, and I may also write up a more thorough fix that tries to make it easy not to fall into the same Git pitfall again. Both now done. * GH-15451 is that minimal fix. * Just now I've posted https://github.com/gnprice/cpython/pull/1 , which is the more thorough fix. It's written on top of the minimal fix, but I could also squash them together as one PR. Also just posted GH-15542 . This is a small edit, deleting some lines whose author evidently never intended them to get committed to the repo. I'd noticed those lines before and been mildly puzzled; writing up the thorough fix caused me to look in the history and see how they were added, and resolve the mystery :). I've kept that as a separate PR just to reduce the number of moving parts in the main one, because the reasoning for it is quite independent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 02:20:23 2019 From: report at bugs.python.org (Carsten Fuchs) Date: Tue, 27 Aug 2019 06:20:23 +0000 Subject: [issue36792] [Windows] time: crash on formatting time with de_DE locale In-Reply-To: <1556973198.72.0.765243261905.issue36792@roundup.psfhosted.org> Message-ID: <1566886823.73.0.172781507469.issue36792@roundup.psfhosted.org> Change by Carsten Fuchs : ---------- nosy: +Carsten Fuchs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 02:27:58 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Aug 2019 06:27:58 +0000 Subject: [issue37957] Allow regrtest to receive a file with test (and subtests) to ignore In-Reply-To: <1566864234.54.0.166621143796.issue37957@roundup.psfhosted.org> Message-ID: <1566887278.57.0.361244785398.issue37957@roundup.psfhosted.org> STINNER Victor added the comment: I'm fine with adding an --excludefile=filename option to regrtest. Do you want to try to implement it? A test can be added in test_regrtest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 02:32:38 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Aug 2019 06:32:38 +0000 Subject: [issue27961] remove support for platforms without "long long" In-Reply-To: <1473119429.61.0.683650779093.issue27961@psf.upfronthosting.co.za> Message-ID: <1566887558.89.0.235767569826.issue27961@roundup.psfhosted.org> Serhiy Storchaka added the comment: This issue was closed 2.5 years ago. Would not be better to open a new issue for new commits? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 02:39:36 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Aug 2019 06:39:36 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566887976.91.0.708058882501.issue36205@roundup.psfhosted.org> STINNER Victor added the comment: Oh, nicely spotted Rajiv Vijayakumar and thanks for the fix! > instead of computing the total time as utime+stime, the code performs utime+utime, which explains the doubling observed. Ooooooops, stupid me :-) I introduced the bug in: commit c29b585fd4b5a91d17fc5dd41d86edff28a30da3 Author: Victor Stinner Date: Thu Nov 2 07:28:27 2017 -0700 bpo-31784: Implement PEP 564: add time.time_ns() (#3989) It seems like macOS was the most visible impacted platform. Windows and Linux has different implementations (GetProcessTimes and clock_gettime(CLOCK_PROCESS_CPUTIME_ID)). Note: I wrote an article about time.perf_counter_ns() added in Python 3.7 (perf_counter, not process_time): https://vstinner.github.io/python37-perf-counter-nanoseconds.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 02:42:32 2019 From: report at bugs.python.org (Shai) Date: Tue, 27 Aug 2019 06:42:32 +0000 Subject: [issue37935] Improve performance of pathlib.scandir() In-Reply-To: <1566628301.14.0.386871182456.issue37935@roundup.psfhosted.org> Message-ID: <1566888152.49.0.579188343833.issue37935@roundup.psfhosted.org> Shai added the comment: >From the docs (https://docs.python.org/3/library/os.html#os.scandir.close): "This is called automatically when the iterator is exhausted or garbage collected, or when an error happens during iterating. However it is advisable to call it explicitly or use the with statement.". The iterator is indeed closed properly, but the docs state that it's still advisable to close it explicitly, which is why I wrapped it in a with statement. However, the more important change is that the iterator is no longer converted into a list, which should reduce the iterations from 2N to N, when N is the number of entries in the directory (one N when converting to list and another one when iterating it). This should enhance the performance of the functions that use scandir. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 02:47:02 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Aug 2019 06:47:02 +0000 Subject: [issue37935] Improve performance of pathlib.scandir() In-Reply-To: <1566628301.14.0.386871182456.issue37935@roundup.psfhosted.org> Message-ID: <1566888422.98.0.210714948941.issue37935@roundup.psfhosted.org> Serhiy Storchaka added the comment: Could you please provide any microbenchmarks that show the performance improvement? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 02:50:23 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Aug 2019 06:50:23 +0000 Subject: [issue37957] Allow regrtest to receive a file with test (and subtests) to ignore In-Reply-To: <1566864234.54.0.166621143796.issue37957@roundup.psfhosted.org> Message-ID: <1566888623.37.0.703761381921.issue37957@roundup.psfhosted.org> Serhiy Storchaka added the comment: Tests that fail on some platforms can be marked to skip in code. For example: @unittest.skipIf(sys.platform.startswith('aix'), 'bpo-29972: broken test on AIX') def test_strcoll_with_diacritic(self): self.assertLess(locale.strcoll('?', 'b'), 0) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 02:54:25 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Aug 2019 06:54:25 +0000 Subject: [issue37957] Allow regrtest to receive a file with test (and subtests) to ignore In-Reply-To: <1566864234.54.0.166621143796.issue37957@roundup.psfhosted.org> Message-ID: <1566888865.24.0.732872433516.issue37957@roundup.psfhosted.org> STINNER Victor added the comment: > Tests that fail on some platforms can be marked to skip in code. We provide best-effort support for AIX, but I consider that Solaris is no longer supported, and so I would prefer to avoid code specific to Soliars in the Python source code. Except if Pablo wants to provide again best-effort support for Solaris? https://pythondev.readthedocs.io/platforms.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 02:56:23 2019 From: report at bugs.python.org (Shai) Date: Tue, 27 Aug 2019 06:56:23 +0000 Subject: [issue37935] Improve performance of pathlib.scandir() In-Reply-To: <1566628301.14.0.386871182456.issue37935@roundup.psfhosted.org> Message-ID: <1566888983.66.0.0842034527114.issue37935@roundup.psfhosted.org> Shai added the comment: I'm new to contributing here. I've never done benchmarking before. I'd appreciate it if you could provide a guide to benchmarking. You could look at the changes I made in the pull request (PR 15331). They're easy to follow and I think that removing a useless call to list() should enhance the performance, but I'd like to have benchmarking to back this up, so if someone more experienced could do this or at least provide a link to a guide, I'd really appreciate it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 02:59:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Aug 2019 06:59:15 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot Message-ID: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> New submission from STINNER Victor : https://buildbot.python.org/all/#/builders/168/builds/1356 test_nop (test.test_os.FSEncodingTests) ... ok test_access (test.test_os.FileTests) ... ok test_closerange (test.test_os.FileTests) ... ok test_copy_file_range (test.test_os.FileTests) ... *** Signal 12 Stop. make: stopped in /usr/home/buildbot/python/3.x.koobs-freebsd-current/build program finished with exit code 1 elapsedTime=1562.592656 man signal says: "12 SIGSYS create core image non-existent system call invoked" I bet that the "non-existent system call" is: copy_file_range. The configure script says: "checking for copy_file_range... yes" Se also bpo-37711: "regrtest: re-run failed tests in subprocesses". ---------- components: Tests messages: 350609 nosy: pablogsal, vstinner priority: normal severity: normal status: open title: test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 03:18:41 2019 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 27 Aug 2019 07:18:41 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566890321.57.0.644755268153.issue36205@roundup.psfhosted.org> Ronald Oussoren added the comment: @raymond, as to your question in msg350586: The release installers are generally build on the oldest release of the OS targeted by the installer. That's to ensure that the binaries actually work there. It should be possible to build on newer releases, but that will require patches to CPython because the build will otherwise use symbols not available on older releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 03:22:40 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Aug 2019 07:22:40 +0000 Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org> Message-ID: <1566890560.75.0.660058883503.issue36205@roundup.psfhosted.org> STINNER Victor added the comment: On PR 12287, Ned Deily wrote: > I still think it would be better to have a test for this case since the problem embarrassingly went undetected for quite some time. But I'll let some one else deal with it if they care to. test_time already contains a functional test on time.process_time() to ensure that sleep isn't included in process time: def test_process_time(self): # process_time() should not include time spend during a sleep start = time.process_time() time.sleep(0.100) stop = time.process_time() # use 20 ms because process_time() has usually a resolution of 15 ms # on Windows self.assertLess(stop - start, 0.020) info = time.get_clock_info('process_time') self.assertTrue(info.monotonic) self.assertFalse(info.adjustable) Writing tests on clocks is really hard, since every single platform has a different resolution. Previous attempts to write "accurate" tests on clock caused a lot of flaky tests making our CIs fail randomly. We removed some tests because of that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 03:23:09 2019 From: report at bugs.python.org (Christoph Deil) Date: Tue, 27 Aug 2019 07:23:09 +0000 Subject: [issue37905] Improve docs for NormalDist In-Reply-To: <1566391134.6.0.700853961099.issue37905@roundup.psfhosted.org> Message-ID: <1566890589.13.0.685020789724.issue37905@roundup.psfhosted.org> Christoph Deil added the comment: Thank you, Raymond! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 03:27:43 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Aug 2019 07:27:43 +0000 Subject: [issue37935] Improve performance of pathlib.scandir() In-Reply-To: <1566628301.14.0.386871182456.issue37935@roundup.psfhosted.org> Message-ID: <1566890863.74.0.0617336313287.issue37935@roundup.psfhosted.org> Serhiy Storchaka added the comment: I think using the timeit module is enough. For more precise benchmarking you may need to use the pyperf module, but I think this is not a case. For example, something like: ./python -m timeit -s "from pathlib import Path; p = Patch('...')" "for x in p.rglob('...'): pass" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 03:49:40 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Aug 2019 07:49:40 +0000 Subject: [issue37960] repr() of buffered and text streams silences too many exceptions Message-ID: <1566892180.39.0.647932070898.issue37960@roundup.psfhosted.org> New submission from Serhiy Storchaka : __repr__() implementations of buffered and text streams try to include the value of "name" and "mode" attributes in the result. But they silence too wide range of exceptions (all subclasses of Exception) when try to get these values. This includes such exceptions as MemoryError or RecursionError which can be occurred in virtually any code. The proposed PR narrows the range of silenced exceptions to the necessary minimum: expected AttributeError and ValueError. The latter is raised if the underlying stream was detached. ---------- components: IO, Library (Lib) messages: 350614 nosy: serhiy.storchaka priority: normal severity: normal status: open title: repr() of buffered and text streams silences too many exceptions type: behavior versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 03:50:04 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Aug 2019 07:50:04 +0000 Subject: [issue37960] repr() of buffered and text streams silences too many exceptions In-Reply-To: <1566892180.39.0.647932070898.issue37960@roundup.psfhosted.org> Message-ID: <1566892204.11.0.416878031188.issue37960@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- nosy: +benjamin.peterson, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 03:56:54 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 27 Aug 2019 07:56:54 +0000 Subject: [issue37960] repr() of buffered and text streams silences too many exceptions In-Reply-To: <1566892180.39.0.647932070898.issue37960@roundup.psfhosted.org> Message-ID: <1566892614.46.0.721600324904.issue37960@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- keywords: +patch pull_requests: +15220 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15543 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 04:15:41 2019 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Aug 2019 08:15:41 +0000 Subject: [issue37951] Disallow fork in a subinterpreter broke subprocesses in mod_wsgi daemon mode In-Reply-To: <1566808952.7.0.710040972846.issue37951@roundup.psfhosted.org> Message-ID: <1566893741.24.0.322088823286.issue37951@roundup.psfhosted.org> Change by Christian Heimes : ---------- keywords: +patch pull_requests: +15221 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15544 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 04:21:56 2019 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Aug 2019 08:21:56 +0000 Subject: [issue37951] Disallow fork in a subinterpreter broke subprocesses in mod_wsgi daemon mode In-Reply-To: <1566808952.7.0.710040972846.issue37951@roundup.psfhosted.org> Message-ID: <1566894116.03.0.895123813376.issue37951@roundup.psfhosted.org> Christian Heimes added the comment: I have created a PR that implements Greg's proposal https://bugs.python.org/issue34651#msg325302 ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 04:23:25 2019 From: report at bugs.python.org (Julien Danjou) Date: Tue, 27 Aug 2019 08:23:25 +0000 Subject: [issue37961] Tracemalloc traces do not include original stack trace length Message-ID: <1566894205.32.0.427554502238.issue37961@roundup.psfhosted.org> New submission from Julien Danjou : When using the tracemalloc module, the maximum number of frames that are captured is specified at startup via a value to the `start` method. However, if the number of frames is truncated, there's no way to know the original length of the stack traces. ---------- components: Interpreter Core messages: 350616 nosy: jd priority: normal severity: normal status: open title: Tracemalloc traces do not include original stack trace length versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 04:25:51 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 27 Aug 2019 08:25:51 +0000 Subject: [issue37961] Tracemalloc traces do not include original stack trace length In-Reply-To: <1566894205.32.0.427554502238.issue37961@roundup.psfhosted.org> Message-ID: <1566894351.17.0.128729943025.issue37961@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 04:26:19 2019 From: report at bugs.python.org (Julien Danjou) Date: Tue, 27 Aug 2019 08:26:19 +0000 Subject: [issue37961] Tracemalloc traces do not include original stack trace length In-Reply-To: <1566894205.32.0.427554502238.issue37961@roundup.psfhosted.org> Message-ID: <1566894379.19.0.653635570763.issue37961@roundup.psfhosted.org> Change by Julien Danjou : ---------- keywords: +patch pull_requests: +15222 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15545 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 04:48:53 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 27 Aug 2019 08:48:53 +0000 Subject: [issue37957] Allow regrtest to receive a file with test (and subtests) to ignore In-Reply-To: <1566864234.54.0.166621143796.issue37957@roundup.psfhosted.org> Message-ID: <1566895733.26.0.988119238612.issue37957@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: > Tests that fail on some platforms can be marked to skip in code. One of the use cases of this feature is for people to package Python at distributions or companies and want to run the test suite without modifying the code or applying patches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 04:58:58 2019 From: report at bugs.python.org (Dong-hee Na) Date: Tue, 27 Aug 2019 08:58:58 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1566896338.23.0.0124629795252.issue37798@roundup.psfhosted.org> Change by Dong-hee Na : ---------- pull_requests: +15223 pull_request: https://github.com/python/cpython/pull/15546 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 05:27:07 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 27 Aug 2019 09:27:07 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1566898027.76.0.295957966747.issue37959@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Oh, FreeBSD, what have you done now..... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 05:29:22 2019 From: report at bugs.python.org (Anders Lorentsen) Date: Tue, 27 Aug 2019 09:29:22 +0000 Subject: [issue31956] Add start and stop parameters to the array.index() In-Reply-To: <1509966827.68.0.213398074469.issue31956@psf.upfronthosting.co.za> Message-ID: <1566898162.9.0.405259936068.issue31956@roundup.psfhosted.org> Anders Lorentsen added the comment: As far as I can recall, the patch is generally speaking good to go. A number of discussions arose on various details, however. In any event, I'll take a look at it during the next few days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 05:30:58 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 27 Aug 2019 09:30:58 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1566898258.37.0.0801863998284.issue37959@roundup.psfhosted.org> Change by Pablo Galindo Salgado : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 05:31:26 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 27 Aug 2019 09:31:26 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1566898286.73.0.243332869731.issue37959@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: @koobs, did you changed recently the buildbot? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 05:33:38 2019 From: report at bugs.python.org (Kubilay Kocak) Date: Tue, 27 Aug 2019 09:33:38 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1566898418.86.0.857084716434.issue37959@roundup.psfhosted.org> Kubilay Kocak added the comment: @Pablo Upgrade to latest CURRENT revision a few hours ago. Some system software is still updating. I'll push a rebuild on BB once complete. Stand by :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 05:36:28 2019 From: report at bugs.python.org (Kubilay Kocak) Date: Tue, 27 Aug 2019 09:36:28 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1566898588.81.0.807466964293.issue37959@roundup.psfhosted.org> Kubilay Kocak added the comment: Possibly related: https://reviews.freebsd.org/D20584 - Add a linux compatible copy_file_range(2) syscall https://lists.freebsd.org/pipermail/freebsd-current/2019-July/073747.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 05:40:19 2019 From: report at bugs.python.org (Kubilay Kocak) Date: Tue, 27 Aug 2019 09:40:19 +0000 Subject: [issue37157] shutil: add reflink=False to file copy functions to control clone/CoW copies (use copy_file_range) In-Reply-To: <1559684200.61.0.18008315195.issue37157@roundup.psfhosted.org> Message-ID: <1566898819.24.0.491669843368.issue37157@roundup.psfhosted.org> Kubilay Kocak added the comment: See Also: #26826 ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 05:40:39 2019 From: report at bugs.python.org (Kubilay Kocak) Date: Tue, 27 Aug 2019 09:40:39 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1566898839.41.0.957299006034.issue37959@roundup.psfhosted.org> Kubilay Kocak added the comment: See Also: #26826 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 06:13:45 2019 From: report at bugs.python.org (qix-) Date: Tue, 27 Aug 2019 10:13:45 +0000 Subject: [issue33944] Deprecate and remove pth files In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za> Message-ID: <1566900825.09.0.687856835044.issue33944@roundup.psfhosted.org> qix- added the comment: -1 This would make `better_exceptions` irreparably un-ergonomic. https://github.com/qix-/better-exceptions .PTH files are commonly used to install development middleware in order to enhance the development and debugging experience. I recognize the need for security, but could we instead focus on improving the security of the existing .PTH system instead of throwing out the baby with the bathwater? The search "pth files python virus|malicious" on Google returns this issue. Is .PTH a previously exploited vector? This is like saying NPM's `install` scripts are a vector. I'm not going to be running code that I don't at least trust a little. This issue reads like someone had a bad time with some poorly written Python code that was stuck inside a .PTH file, had to debug why it was causing a problem, and came here to cry about it (no offense, Barry). Instead of improving it, the first inclination was to remove it altogether without any regard to its use-cases or the effects it would have on some packages that rely on it. Let's improve it, not kill it. ---------- nosy: +qix- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 06:13:55 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Aug 2019 10:13:55 +0000 Subject: [issue37957] Allow regrtest to receive a file with test (and subtests) to ignore In-Reply-To: <1566864234.54.0.166621143796.issue37957@roundup.psfhosted.org> Message-ID: <1566900835.39.0.00957424361028.issue37957@roundup.psfhosted.org> STINNER Victor added the comment: FYI in the past, Fedora and RHEL packages skipped multiple tests using downstream patches. Hopefully, we managed to reenable almost all tests. Currently in Fedora, the python3 package use regrtest -x to skip some tests: # Run the upstream test suite # test_gdb skipped on s390x: # https://bugzilla.redhat.com/show_bug.cgi?id=1678277 # test_gdb skipped everywhere: # https://bugzilla.redhat.com/show_bug.cgi?id=1734327 # test_distutils # distutils.tests.test_bdist_rpm tests fail when bootstraping the Python # package: rpmbuild requires /usr/bin/pythonX.Y to be installed LD_LIBRARY_PATH=$ConfDir $ConfDir/python -m test.regrtest \ -wW --slowest -j0 \ %if %{with bootstrap} -x test_distutils \ %endif -x test_gdb \ %ifarch %{mips64} -x test_ctypes \ %endif https://src.fedoraproject.org/rpms/python3/blob/master/f/python3.spec We could only skip some test methods, but it's simpler for us to skip a whole test file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 06:14:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Aug 2019 10:14:39 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1566900879.59.0.914269083171.issue37959@roundup.psfhosted.org> STINNER Victor added the comment: It would be better if the FreeBSD kernel would return ENOSYS error code rather than killing the process with SIGSYS :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 07:46:03 2019 From: report at bugs.python.org (Kubilay Kocak) Date: Tue, 27 Aug 2019 11:46:03 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1566906363.04.0.789109152434.issue37959@roundup.psfhosted.org> Kubilay Kocak added the comment: Hmm... a test checkout of master/default on the host in question has test_copy_file_range{_*} passing: [user at CURRENT-amd64:/usr/home/user/repos/cpython] ./python -m test -vvv test_os |grep range ... test_copy_file_range (test.test_os.FileTests) ... ok test_copy_file_range_invalid_values (test.test_os.FileTests) ... ok test_copy_file_range_offset (test.test_os.FileTests) ... ok ... Ran 280 tests in 2.503s OK (skipped=45) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 07:54:32 2019 From: report at bugs.python.org (STINNER Victor) Date: Tue, 27 Aug 2019 11:54:32 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1566906872.19.0.00541078953929.issue37959@roundup.psfhosted.org> STINNER Victor added the comment: > https://buildbot.python.org/all/#/builders/168/builds/1356 Just to confirm: test_os was run twice and was killed twice by signal 12. 0:00:04 load avg: 3.45 [ 8/419/1] test_os crashed (Exit code -12) ... Re-running failed tests in verbose mode Re-running test_os in verbose mode ... test_copy_file_range (test.test_os.FileTests) ... *** Signal 12 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 08:07:38 2019 From: report at bugs.python.org (Zeth) Date: Tue, 27 Aug 2019 12:07:38 +0000 Subject: [issue37962] Improve ISO 8601 timezone support in the datetime.fromisoformat() method Message-ID: <1566907658.52.0.492553753506.issue37962@roundup.psfhosted.org> New submission from Zeth : The datetime.datetime.fromisoformat() method unnecessarily rejects datetime strings that are valid under ISO 8601 if timezone uses the UTC designator or it only has hours. In ISO 8601, section 4.2.5.1: "When it is required to indicate the difference between local time and UTC of day, the representation of the difference can be expressed in hours and minutes, or hours only." And Section 4.2.4, UTC shall be expressed "by the UTC designator [Z]". A key use case of the latter is being able to parse JavaScript Date objects (e.g. dates that have come from a web frontend or a JSON document). This considerably improves the usefulness of the datetime.fromisoformat method. ---------- messages: 350630 nosy: zeth priority: normal pull_requests: 15224 severity: normal status: open title: Improve ISO 8601 timezone support in the datetime.fromisoformat() method _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 08:16:29 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Tue, 27 Aug 2019 12:16:29 +0000 Subject: [issue37962] Improve ISO 8601 timezone support in the datetime.fromisoformat() method In-Reply-To: <1566907658.52.0.492553753506.issue37962@roundup.psfhosted.org> Message-ID: <1566908190.0.0.582862477337.issue37962@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +belopolsky, p-ganssle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 08:20:17 2019 From: report at bugs.python.org (Kubilay Kocak) Date: Tue, 27 Aug 2019 12:20:17 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1566908417.34.0.442905406085.issue37959@roundup.psfhosted.org> Kubilay Kocak added the comment: Ran rebuild (in the BB UI) on that failed build (#1356), and test_os now passes: 0:22:52 load avg: 8.38 [339/419] test_os passed Victor independently logged into the host and ran a from scratch build/test and test_os passes for him too (verifying my from scratch test results) Only thing I can think of is a cached/inconsistent BB build environment after the host FreeBSD update, that cleared itself after the first build ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 08:51:09 2019 From: report at bugs.python.org (Patrik Kopkan) Date: Tue, 27 Aug 2019 12:51:09 +0000 Subject: [issue37064] Feature request: option to keep/add flags to pathfix. In-Reply-To: <1558962587.87.0.563974081614.issue37064@roundup.psfhosted.org> Message-ID: <1566910269.96.0.249603962119.issue37064@roundup.psfhosted.org> Change by Patrik Kopkan : ---------- pull_requests: +15225 pull_request: https://github.com/python/cpython/pull/15548 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 08:59:01 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 27 Aug 2019 12:59:01 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1566910741.98.0.739527006396.issue37959@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Could this be that the libc was outdated? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 10:36:37 2019 From: report at bugs.python.org (Paul Ganssle) Date: Tue, 27 Aug 2019 14:36:37 +0000 Subject: [issue37962] Improve ISO 8601 timezone support in the datetime.fromisoformat() method In-Reply-To: <1566907658.52.0.492553753506.issue37962@roundup.psfhosted.org> Message-ID: <1566916597.79.0.34067667411.issue37962@roundup.psfhosted.org> Paul Ganssle added the comment: This is a duplicate of #35829. The reason that 'Z' is not supported is that `fromisoformat()` is not a general ISO 8601 parser, but rather is intended to be the inverse of `isoformat()`. See the documentation here: https://docs.python.org/dev/library/datetime.html#datetime.datetime.fromisoformat The current state of #35829 is that expanding to support all of ISO 8601 is an option, but determining the scope an the API are a bit tricky. ISO 8601 is more complicated than most people think. In the meantime, `dateutil.parser.isoparse` is intentionally scoped to parse all valid ISO 8601 datetimes. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> datetime: parse "Z" timezone suffix in fromisoformat() type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 10:51:02 2019 From: report at bugs.python.org (=?utf-8?q?Thomas_G=C3=BCttler?=) Date: Tue, 27 Aug 2019 14:51:02 +0000 Subject: [issue37963] No URL for docs of pth files Message-ID: <1566917462.27.0.631733525423.issue37963@roundup.psfhosted.org> New submission from Thomas G?ttler : if you google for "python pth" you get to the "sites" docs. It would be very nice if you could create a direct URL to the docs of pth files. This makes it easier to point new comers into the right direction if you answer questions at stackoverflow (or other places). See: https://www.google.com/search?q=python+pth ---------- messages: 350634 nosy: Thomas G?ttler priority: normal severity: normal status: open title: No URL for docs of pth files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 10:53:19 2019 From: report at bugs.python.org (Vinay Sharma) Date: Tue, 27 Aug 2019 14:53:19 +0000 Subject: [issue37964] F_GETPATH is not available in fcntl.fcntl Message-ID: <1566917599.68.0.248827592945.issue37964@roundup.psfhosted.org> New submission from Vinay Sharma : F_GETPATH cmd/operator is not present in fcntl module. This is specific to macos and is only available in macos. https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fcntl.2.html This can be also be verified using `man fcntl` ---------- components: Library (Lib) messages: 350635 nosy: twouters, vinay0410 priority: normal severity: normal status: open title: F_GETPATH is not available in fcntl.fcntl type: enhancement versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 10:56:29 2019 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Aug 2019 14:56:29 +0000 Subject: [issue37964] F_GETPATH is not available in fcntl.fcntl In-Reply-To: <1566917599.68.0.248827592945.issue37964@roundup.psfhosted.org> Message-ID: <1566917789.26.0.160372788805.issue37964@roundup.psfhosted.org> Christian Heimes added the comment: Since it's a feature request, I have reset the version list to 3.9. ---------- nosy: +christian.heimes stage: -> needs patch versions: -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 11:55:00 2019 From: report at bugs.python.org (Vinay Sharma) Date: Tue, 27 Aug 2019 15:55:00 +0000 Subject: [issue37964] F_GETPATH is not available in fcntl.fcntl In-Reply-To: <1566917599.68.0.248827592945.issue37964@roundup.psfhosted.org> Message-ID: <1566921300.07.0.395836551617.issue37964@roundup.psfhosted.org> Change by Vinay Sharma : ---------- keywords: +patch pull_requests: +15226 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15550 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 12:16:31 2019 From: report at bugs.python.org (Vinay Sharma) Date: Tue, 27 Aug 2019 16:16:31 +0000 Subject: [issue37964] F_GETPATH is not available in fcntl.fcntl In-Reply-To: <1566917599.68.0.248827592945.issue37964@roundup.psfhosted.org> Message-ID: <1566922591.31.0.483402859916.issue37964@roundup.psfhosted.org> Vinay Sharma added the comment: I have opened a PR, but no reviewers, have been assigned. Could you please look into that ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 13:41:58 2019 From: report at bugs.python.org (hai shi) Date: Tue, 27 Aug 2019 17:41:58 +0000 Subject: [issue9351] argparse set_defaults on subcommands should override top level set_defaults In-Reply-To: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za> Message-ID: <1566927718.39.0.345897096728.issue9351@roundup.psfhosted.org> hai shi added the comment: How about use a flag(such USING_OUT_NAMESPACE) to identify we use namespace or not? For example: subnamespace, arg_strings = parser.parse_known_args(arg_strings, None) for key, value in vars(subnamespace).items(): if USING_OUT_NAMESPACE and not hasattr(namespace, key): setattr(namespace, key, value) ---------- nosy: +shihai1991 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 14:00:22 2019 From: report at bugs.python.org (Tal Einat) Date: Tue, 27 Aug 2019 18:00:22 +0000 Subject: [issue37827] IDLE Shell: add a terminal mode that responds to \a, \b, and \r In-Reply-To: <1565592773.8.0.657523892243.issue37827@roundup.psfhosted.org> Message-ID: <1566928822.17.0.748988838738.issue37827@roundup.psfhosted.org> Tal Einat added the comment: Terry, thanks for the detailed writing of your thoughts on the matter and their context. Serhiy's argument (in msg246602) is that different terminals interpret different control characters in different ways, and that we have no way of unifying their behavior. This is true, and I will add that we should also not aim to fully emulate any single terminal nor multiple types of terminals. On the other hand, there is a common ground where the vast majority of terminals do, in fact, behave very similarly WRT control characters. For example, IDLE already does interpret '\n' in a special way (partially because the underlying Tk text widget does). The same goes for '\t'. I argue that we should instead *slightly* expand the set of control characters which IDLE interprets, to include a few more which are universally treated in a consistent manner. Looking at the list of ASCII control characters on Wikipedia[1], I don't think any beyond \a, \b, \n, \r and \t are universal enough and in common enough use to merit inclusion. (For reference, \a is for "bell".) ..[1]: https://en.wikipedia.org/wiki/C0_and_C1_control_codes I find the suggestion to have more than a single "mode" for the IDLE shell contrary to the "simple and novice friendly" design principle that we are aiming for. I also think that it would bring little added benefit to the great majority of our users. As for other control characters and astral characters, I very much agree that we could do better than to have them often "garbled" as done by the Tk text widget. I think this should be dealt with as a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 14:16:44 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 27 Aug 2019 18:16:44 +0000 Subject: [issue37936] gitignore file is too broad In-Reply-To: <1566630912.92.0.00349300289224.issue37936@roundup.psfhosted.org> Message-ID: <1566929804.29.0.106620228193.issue37936@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15227 pull_request: https://github.com/python/cpython/pull/15552 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 14:16:47 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 27 Aug 2019 18:16:47 +0000 Subject: [issue37936] gitignore file is too broad In-Reply-To: <1566630912.92.0.00349300289224.issue37936@roundup.psfhosted.org> Message-ID: <1566929807.55.0.963660881941.issue37936@roundup.psfhosted.org> miss-islington added the comment: New changeset 8c9e9b0cd5b24dfbf1424d1f253d02de80e8f5ef by Miss Islington (bot) (Greg Price) in branch 'master': bpo-37936: Remove some .gitignore rules that were intended locally. (GH-15542) https://github.com/python/cpython/commit/8c9e9b0cd5b24dfbf1424d1f253d02de80e8f5ef ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 14:16:51 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 27 Aug 2019 18:16:51 +0000 Subject: [issue37936] gitignore file is too broad In-Reply-To: <1566630912.92.0.00349300289224.issue37936@roundup.psfhosted.org> Message-ID: <1566929811.55.0.461537399926.issue37936@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15228 pull_request: https://github.com/python/cpython/pull/15553 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 14:35:15 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 27 Aug 2019 18:35:15 +0000 Subject: [issue37936] gitignore file is too broad In-Reply-To: <1566630912.92.0.00349300289224.issue37936@roundup.psfhosted.org> Message-ID: <1566930915.72.0.829888169926.issue37936@roundup.psfhosted.org> miss-islington added the comment: New changeset caf7a30efecef21def997ab214dc6c1604d90a84 by Miss Islington (bot) in branch '3.8': bpo-37936: Remove some .gitignore rules that were intended locally. (GH-15542) https://github.com/python/cpython/commit/caf7a30efecef21def997ab214dc6c1604d90a84 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 14:41:41 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 27 Aug 2019 18:41:41 +0000 Subject: [issue37936] gitignore file is too broad In-Reply-To: <1566630912.92.0.00349300289224.issue37936@roundup.psfhosted.org> Message-ID: <1566931301.31.0.359352080992.issue37936@roundup.psfhosted.org> miss-islington added the comment: New changeset 2f0440e6dba248ff1e2b46c063adfd8fcb923a34 by Miss Islington (bot) in branch '3.7': bpo-37936: Remove some .gitignore rules that were intended locally. (GH-15542) https://github.com/python/cpython/commit/2f0440e6dba248ff1e2b46c063adfd8fcb923a34 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 14:49:39 2019 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 27 Aug 2019 18:49:39 +0000 Subject: [issue37827] IDLE Shell: add a terminal mode that responds to \a, \b, and \r In-Reply-To: <1565592773.8.0.657523892243.issue37827@roundup.psfhosted.org> Message-ID: <1566931779.37.0.470624051338.issue37827@roundup.psfhosted.org> Change by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 15:23:31 2019 From: report at bugs.python.org (Paul Ganssle) Date: Tue, 27 Aug 2019 19:23:31 +0000 Subject: [issue35829] datetime: parse "Z" timezone suffix in fromisoformat() In-Reply-To: <1548445007.56.0.14925163397.issue35829@roundup.psfhosted.org> Message-ID: <1566933811.34.0.76775617565.issue35829@roundup.psfhosted.org> Paul Ganssle added the comment: > Defining isoformat() and fromisoformat() as functional inverses is misguided. Indeed, it's not even true: `isoformat()` is not the inverse of `fromisoformat()`, that doesn't work because there are multiple strings that isoformat() can create from any given datetime. There is, however, only one datetime that is represented by any given datetime (assuming you consider truncation to create a new datetime), so it is fine for fromisoformat() to be the inverse of isoformat(). I have explained the reason that was chosen for the contract in several places (including in this thread), so I won't bother to repeat it. I think from a practical point of view we should eventually grow more generalized ISO 8601 parsing functionality, and the main question is what the API will look like. In dateutil.parser.isoparse, I still haven't figured out a good way to do feature flags. > I'd be willing to work on a PR, but a change of this size probably needs to through python-ideas first? I don't think it *needs* to go to python-ideas, though it's probably a good idea to try and work out the optimal API in a post on the discourse ( discuss.python.org ), and the "ideas" category seems like the right one there. Please CC me (pganssle) if you propose modifications to the fromisoformat API on the discourse. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 15:35:24 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Tue, 27 Aug 2019 19:35:24 +0000 Subject: [issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots In-Reply-To: <1566829813.13.0.292904797891.issue37954@roundup.psfhosted.org> Message-ID: <1566934524.13.0.734325330507.issue37954@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Thank you very much, Steve! This was indeed a bit tricky :) The last refleak buildbot is green again, so closing this. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 16:40:43 2019 From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=) Date: Tue, 27 Aug 2019 20:40:43 +0000 Subject: [issue37894] [win] shutil.which can not find the path if 'cmd' include directory path and not include extension name In-Reply-To: <1566316777.4.0.882745227499.issue37894@roundup.psfhosted.org> Message-ID: <1566938443.74.0.231061259531.issue37894@roundup.psfhosted.org> Change by ????? ???????? : ---------- nosy: +SpecLad _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 16:43:10 2019 From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=) Date: Tue, 27 Aug 2019 20:43:10 +0000 Subject: [issue24505] shutil.which wrong result on Windows In-Reply-To: <1435183779.2.0.13075721906.issue24505@psf.upfronthosting.co.za> Message-ID: <1566938590.47.0.195826649741.issue24505@roundup.psfhosted.org> Change by ????? ???????? : ---------- nosy: +SpecLad _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 16:45:37 2019 From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=) Date: Tue, 27 Aug 2019 20:45:37 +0000 Subject: [issue31405] shutil.which doesn't find files without PATHEXT extension on Windows In-Reply-To: <1504980729.07.0.774720722316.issue31405@psf.upfronthosting.co.za> Message-ID: <1566938737.15.0.595998930643.issue31405@roundup.psfhosted.org> Change by ????? ???????? : ---------- nosy: +SpecLad _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 16:46:19 2019 From: report at bugs.python.org (=?utf-8?b?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?=) Date: Tue, 27 Aug 2019 20:46:19 +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: <1566938779.38.0.556903172996.issue35964@roundup.psfhosted.org> Change by ????? ???????? : ---------- nosy: +SpecLad _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 16:47:14 2019 From: report at bugs.python.org (Maarten) Date: Tue, 27 Aug 2019 20:47:14 +0000 Subject: [issue37965] CCompiler has_function displays warning Message-ID: <1566938834.78.0.244631078662.issue37965@roundup.psfhosted.org> New submission from Maarten : When using the `has_function` method of a CCompiler object, the compiler will emit a warning because the main function has no return type specified. https://github.com/python/cpython/blob/8c9e9b0cd5b24dfbf1424d1f253d02de80e8f5ef/Lib/distutils/ccompiler.py#L784-L786 This warning is emitted: /tmp/clockq2_azlzj.c:2:1: warning: return type defaults to ?int? [-Wimplicit-int] 2 | main (int argc, char **argv) { | ^~~~ This happens under Linux, gcc 9 ---------- components: Distutils files: 0001-Fix-compiler-warning-of-distutils-CCompiler.test_fun.patch keywords: patch messages: 350645 nosy: dstufft, eric.araujo, maarten priority: normal severity: normal status: open title: CCompiler has_function displays warning type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file48563/0001-Fix-compiler-warning-of-distutils-CCompiler.test_fun.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 17:37:00 2019 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Aug 2019 21:37:00 +0000 Subject: [issue37951] Disallow fork in a subinterpreter broke subprocesses in mod_wsgi daemon mode In-Reply-To: <1566808952.7.0.710040972846.issue37951@roundup.psfhosted.org> Message-ID: <1566941820.24.0.220956576984.issue37951@roundup.psfhosted.org> Christian Heimes added the comment: New changeset 98d90f745d35d5d07bffcb46788b50e05eea56c6 by Christian Heimes in branch 'master': bpo-37951: Lift subprocess's fork() restriction (GH-15544) https://github.com/python/cpython/commit/98d90f745d35d5d07bffcb46788b50e05eea56c6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 17:37:28 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 27 Aug 2019 21:37:28 +0000 Subject: [issue37951] Disallow fork in a subinterpreter broke subprocesses in mod_wsgi daemon mode In-Reply-To: <1566808952.7.0.710040972846.issue37951@roundup.psfhosted.org> Message-ID: <1566941848.32.0.986555247894.issue37951@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15229 pull_request: https://github.com/python/cpython/pull/15554 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 17:56:30 2019 From: report at bugs.python.org (miss-islington) Date: Tue, 27 Aug 2019 21:56:30 +0000 Subject: [issue37951] Disallow fork in a subinterpreter broke subprocesses in mod_wsgi daemon mode In-Reply-To: <1566808952.7.0.710040972846.issue37951@roundup.psfhosted.org> Message-ID: <1566942990.45.0.995775567879.issue37951@roundup.psfhosted.org> miss-islington added the comment: New changeset 03c52f2f63a8abeb4afb75e9da46c7d6c0a8afd5 by Miss Islington (bot) in branch '3.8': bpo-37951: Lift subprocess's fork() restriction (GH-15544) https://github.com/python/cpython/commit/03c52f2f63a8abeb4afb75e9da46c7d6c0a8afd5 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 17:57:54 2019 From: report at bugs.python.org (Christian Heimes) Date: Tue, 27 Aug 2019 21:57:54 +0000 Subject: [issue37951] Disallow fork in a subinterpreter broke subprocesses in mod_wsgi daemon mode In-Reply-To: <1566808952.7.0.710040972846.issue37951@roundup.psfhosted.org> Message-ID: <1566943074.04.0.879886036051.issue37951@roundup.psfhosted.org> Christian Heimes added the comment: Thanks Victor and Gregory! I'm reducing the severity from release blocker to high and keep the ticket in pending to give Eric a change to review the commits. ---------- priority: release blocker -> high resolution: -> fixed stage: patch review -> commit review status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 21:16:38 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 28 Aug 2019 01:16:38 +0000 Subject: [issue35028] Off by one error in cgi.FieldStorage(max_num_fields) In-Reply-To: <1539974216.92.0.788709270274.issue35028@psf.upfronthosting.co.za> Message-ID: <1566954998.13.0.512620332501.issue35028@roundup.psfhosted.org> Change by Benjamin Peterson : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 21:42:33 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 28 Aug 2019 01:42:33 +0000 Subject: [issue37965] CCompiler has_function displays warning In-Reply-To: <1566938834.78.0.244631078662.issue37965@roundup.psfhosted.org> Message-ID: <1566956553.08.0.894979287358.issue37965@roundup.psfhosted.org> Benjamin Peterson added the comment: seems like a good patch. Can you submit a PR? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 22:57:36 2019 From: report at bugs.python.org (Kubilay Kocak) Date: Wed, 28 Aug 2019 02:57:36 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1566961056.33.0.100924181188.issue37959@roundup.psfhosted.org> Kubilay Kocak added the comment: Possibly, but unlikely as the system had been freshly installed and rebooted before the worker was restarted. The worker processes, however, had not been stopped prior to, or during the upgrade, so it's possible that the worker had an inconsistent build state that had resumed, or used before-upgrade information, code or objects during tests ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Aug 27 23:52:56 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 28 Aug 2019 03:52:56 +0000 Subject: [issue37966] is_normalized is much slower than the standard's algorithm Message-ID: <1566964376.46.0.968905414274.issue37966@roundup.psfhosted.org> New submission from Greg Price : In 3.8 we add a new function `unicodedata.is_normalized`. The result is equivalent to `str == unicodedata.normalize(form, str)`, but the implementation uses a version of the "quick check" algorithm from UAX #15 as an optimization to try to avoid having to copy the whole string. This was added in issue #32285, commit 2810dd7be. However, it turns out the code doesn't actually implement the same algorithm as UAX #15, and as a result we often miss the optimization and end up having to compute the whole normalized string after all. Here's a quick demo on my desktop. We pass a long string made entirely out of a character for which the quick-check algorithm always says `NO`, it's not normalized: $ build.base/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' -- \ 'unicodedata.is_normalized("NFD", s)' 50 loops, best of 5: 4.39 msec per loop $ build.base/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' -- \ 's == unicodedata.normalize("NFD", s)' 50 loops, best of 5: 4.41 msec per loop That's the same 4.4 ms (for a 1 MB string) with or without the attempted optimization. Here it is after a patch that makes the algorithm run as in the standard: $ build.dev/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' -- \ 'unicodedata.is_normalized("NFD", s)' 5000000 loops, best of 5: 58.2 nsec per loop Nearly 5 orders of magnitude faster -- the difference between O(N) and O(1). The root cause of the issue is that our `is_normalized` static helper, which the new function relies on, was never written as a full implementation of the quick-check algorithm. The full algorithm can return YES, MAYBE, or NO; but originally this helper's only caller was the implementation of `unicodedata.normalize`, which only cares about YES vs. MAYBE-or-NO. So the helper often returns MAYBE when the standard algorithm would say NO. (More precisely, perhaps: it's fine that this helper was never a full implementation... but it didn't say that anywhere, even while referring to the standard algorithm, and as a result set us up for future confusion.) That's exactly what's happening in the example above: the standard quick-check algorithm would say NO, but our helper says MAYBE. Which for `unicodedata.is_normalized` means it has to go compute the whole normalized string. ---------- messages: 350651 nosy: Greg Price priority: normal severity: normal status: open title: is_normalized is much slower than the standard's algorithm versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 00:34:40 2019 From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=) Date: Wed, 28 Aug 2019 04:34:40 +0000 Subject: [issue34651] Disallow fork in a subinterpreter. In-Reply-To: <1536786263.28.0.956365154283.issue34651@psf.upfronthosting.co.za> Message-ID: <1566966880.98.0.717296095069.issue34651@roundup.psfhosted.org> Miro Hron?ok added the comment: The problem with subprocess.Popen has been fixed in https://bugs.python.org/issue37951 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 00:38:13 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 28 Aug 2019 04:38:13 +0000 Subject: [issue36582] collections.UserString encode method returns a string In-Reply-To: <1554853133.32.0.976890929788.issue36582@roundup.psfhosted.org> Message-ID: <1566967093.09.0.127758480262.issue36582@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 2a16eea71f56c2d8f38c295c8ce71a9a9a140aff by Raymond Hettinger (Daniel Fortunov) in branch 'master': bpo-36582: Make collections.UserString.encode() return bytes, not str (GH-13138) https://github.com/python/cpython/commit/2a16eea71f56c2d8f38c295c8ce71a9a9a140aff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 00:38:24 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 28 Aug 2019 04:38:24 +0000 Subject: [issue36582] collections.UserString encode method returns a string In-Reply-To: <1554853133.32.0.976890929788.issue36582@roundup.psfhosted.org> Message-ID: <1566967104.39.0.0168854377585.issue36582@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15230 pull_request: https://github.com/python/cpython/pull/15557 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 00:38:55 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 28 Aug 2019 04:38:55 +0000 Subject: [issue36582] collections.UserString encode method returns a string In-Reply-To: <1554853133.32.0.976890929788.issue36582@roundup.psfhosted.org> Message-ID: <1566967135.8.0.188999171327.issue36582@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- versions: +Python 3.9 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 00:57:51 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 28 Aug 2019 04:57:51 +0000 Subject: [issue37966] is_normalized is much slower than the standard's algorithm In-Reply-To: <1566964376.46.0.968905414274.issue37966@roundup.psfhosted.org> Message-ID: <1566968271.92.0.241018323528.issue37966@roundup.psfhosted.org> Change by Greg Price : ---------- keywords: +patch pull_requests: +15231 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15558 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 00:59:57 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 28 Aug 2019 04:59:57 +0000 Subject: [issue36582] collections.UserString encode method returns a string In-Reply-To: <1554853133.32.0.976890929788.issue36582@roundup.psfhosted.org> Message-ID: <1566968397.36.0.184405951224.issue36582@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 2cb82d2a88710b0af10b9d9721a9710ecc037e72 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-36582: Make collections.UserString.encode() return bytes, not str (GH-13138) (GH-15557) https://github.com/python/cpython/commit/2cb82d2a88710b0af10b9d9721a9710ecc037e72 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 01:00:29 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 28 Aug 2019 05:00:29 +0000 Subject: [issue36582] collections.UserString encode method returns a string In-Reply-To: <1554853133.32.0.976890929788.issue36582@roundup.psfhosted.org> Message-ID: <1566968429.64.0.272630321592.issue36582@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 Aug 28 01:04:42 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 28 Aug 2019 05:04:42 +0000 Subject: [issue37966] is_normalized is much slower at "no" than the standard's algorithm In-Reply-To: <1566964376.46.0.968905414274.issue37966@roundup.psfhosted.org> Message-ID: <1566968682.39.0.61249485596.issue37966@roundup.psfhosted.org> Greg Price added the comment: Fix posted, as GH-15558. Adding cc's for the folks in the thread on #32285, where this function was originally added. ---------- components: +Unicode nosy: +Maxime Belanger, benjamin.peterson, ezio.melotti, steven.daprano, vstinner title: is_normalized is much slower than the standard's algorithm -> is_normalized is much slower at "no" than the standard's algorithm versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 01:09:27 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 28 Aug 2019 05:09:27 +0000 Subject: [issue6331] Add unicode script info to the unicode database In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za> Message-ID: <1566968967.67.0.575931278531.issue6331@roundup.psfhosted.org> Change by Greg Price : ---------- nosy: +Greg Price _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 01:21:17 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 28 Aug 2019 05:21:17 +0000 Subject: [issue37428] SSLContext.post_handshake_auth implicitly enables cert validation In-Reply-To: <1561631609.42.0.922673247425.issue37428@roundup.psfhosted.org> Message-ID: <1566969677.05.0.688885309815.issue37428@roundup.psfhosted.org> Christian Heimes added the comment: 3.7 to 3.9 are fixed. Benjamin, do you want the fix in 2.7? ---------- priority: release blocker -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 01:21:29 2019 From: report at bugs.python.org (Christian Heimes) Date: Wed, 28 Aug 2019 05:21:29 +0000 Subject: [issue37440] httplib should enable post-handshake authentication for TLS 1.3 In-Reply-To: <1561732145.9.0.0353203933987.issue37440@roundup.psfhosted.org> Message-ID: <1566969689.17.0.669409932681.issue37440@roundup.psfhosted.org> Christian Heimes added the comment: 3.7 to 3.9 are fixed. Benjamin, do you want the fix in 2.7? ---------- priority: release blocker -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 01:36:13 2019 From: report at bugs.python.org (Zeth) Date: Wed, 28 Aug 2019 05:36:13 +0000 Subject: [issue37962] Improve ISO 8601 timezone support in the datetime.fromisoformat() method In-Reply-To: <1566907658.52.0.492553753506.issue37962@roundup.psfhosted.org> Message-ID: <1566970573.83.0.212597978405.issue37962@roundup.psfhosted.org> Zeth added the comment: Did you read the attached PR? For three lines longer, the method becomes more generally useful now. As pointed out in the other thread that you pointed to, Javascript can parse Python's seralised datetime object but Python cannot parse Javascript's due to the fact that you don't want to. That other thread points to a third thread that starts in 2012 so it seems that you really think that is a feature rather than a bug. The name of the method is fromisoformat, not "parse our internal home made format". The line in the documentation seems a bit weird to me to be honest. It is saying that we could make it generally useful for you user but we don't want to. The reply to this bug, "use the dateutil.parser.isoparse that I maintain instead" is beside the point, we are talking about the standard library one. Why not put that in the standard library then if it can actually parse iso 8601 format? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 01:55:19 2019 From: report at bugs.python.org (Greg Price) Date: Wed, 28 Aug 2019 05:55:19 +0000 Subject: [issue37837] add internal _PyLong_FromUnsignedChar() function In-Reply-To: <1565692195.8.0.862568192553.issue37837@roundup.psfhosted.org> Message-ID: <1566971719.1.0.335496996599.issue37837@roundup.psfhosted.org> Greg Price added the comment: Ah OK, that makes sense of it then :) > But the most important thing is that using PyLong_FromUnsignedLong() instead of _PyLong_FromUnsignedChar() on top of GH-15192 is producing the same results: striter_next() uses small_ints[] directly. However that's not true for bytearrayiter_next(): PyLong_FromUnsignedLong() is called there. I think that's due to how code is profiled so I'm satisfied with these results more or less. Very interesting! That's a good comparison to have made, too. I agree with your conclusions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 03:38:37 2019 From: report at bugs.python.org (mattip) Date: Wed, 28 Aug 2019 07:38:37 +0000 Subject: [issue37967] release candidate is not gpg signed (and missing release workflow)? Message-ID: <1566977917.52.0.520116504637.issue37967@roundup.psfhosted.org> New submission from mattip : Over at [multibuild](https://github.com/pypa/manylinux/pull/333#issuecomment-519802858), they ran into an issue trying to build c-extensions with the 3.8rc3 since it seems it is not gpg signed. I could not find a HOWTO_RELEASE document to check that the release workflow includes signing the package. One exists in Tools/msi/README.txt. ---------- components: Installation messages: 350660 nosy: mattip priority: normal severity: normal status: open title: release candidate is not gpg signed (and missing release workflow)? type: security versions: Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 03:48:37 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 28 Aug 2019 07:48:37 +0000 Subject: [issue37967] release candidate is not gpg signed (and missing release workflow)? In-Reply-To: <1566977917.52.0.520116504637.issue37967@roundup.psfhosted.org> Message-ID: <1566978517.84.0.142964992307.issue37967@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +lukasz.langa, ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 07:08:12 2019 From: report at bugs.python.org (hongweipeng) Date: Wed, 28 Aug 2019 11:08:12 +0000 Subject: [issue37806] Infinite recursion with typing.get_type_hints In-Reply-To: <1565414817.02.0.248356075738.issue37806@roundup.psfhosted.org> Message-ID: <1566990492.51.0.234937066372.issue37806@roundup.psfhosted.org> Change by hongweipeng : ---------- pull_requests: +15232 pull_request: https://github.com/python/cpython/pull/15559 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 07:39:21 2019 From: report at bugs.python.org (Maarten) Date: Wed, 28 Aug 2019 11:39:21 +0000 Subject: [issue37965] CCompiler has_function displays warning In-Reply-To: <1566938834.78.0.244631078662.issue37965@roundup.psfhosted.org> Message-ID: <1566992361.28.0.194236604873.issue37965@roundup.psfhosted.org> Change by Maarten : ---------- pull_requests: +15233 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15560 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 07:56:01 2019 From: report at bugs.python.org (Dominic Littlewood) Date: Wed, 28 Aug 2019 11:56:01 +0000 Subject: [issue37953] Fix ForwardRef equality checks In-Reply-To: <1566828364.46.0.753751170409.issue37953@roundup.psfhosted.org> Message-ID: <1566993361.29.0.397896403697.issue37953@roundup.psfhosted.org> Change by Dominic Littlewood <11dlittlewood at gmail.com>: ---------- keywords: +patch pull_requests: +15235 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15400 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 07:57:46 2019 From: report at bugs.python.org (Maarten) Date: Wed, 28 Aug 2019 11:57:46 +0000 Subject: [issue37965] CCompiler has_function displays warning In-Reply-To: <1566938834.78.0.244631078662.issue37965@roundup.psfhosted.org> Message-ID: <1566993466.7.0.441243025082.issue37965@roundup.psfhosted.org> Maarten added the comment: I have submitted a PR to github: https://github.com/python/cpython/pull/15560 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 08:58:20 2019 From: report at bugs.python.org (Yehuda Katz) Date: Wed, 28 Aug 2019 12:58:20 +0000 Subject: [issue37968] The turtle Message-ID: <1566997100.11.0.991948132497.issue37968@roundup.psfhosted.org> New submission from Yehuda Katz : 1 - turtle bug: If I don't put parenthesis at the end of a line, I don't get error message. Try this: ==================== from turtle import * fd(50); rt done() ==================== 2 - request: Highly desirable a function that draws a circle with radius n AROUND THE TURTLE. Thank you and have a wonderful day. ---------- files: untitled.py messages: 350662 nosy: Yehuda priority: normal severity: normal status: open title: The turtle versions: Python 3.7 Added file: https://bugs.python.org/file48564/untitled.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 10:34:21 2019 From: report at bugs.python.org (sebix) Date: Wed, 28 Aug 2019 14:34:21 +0000 Subject: [issue13824] argparse.FileType opens a file and never closes it In-Reply-To: <1326975939.94.0.524131708506.issue13824@psf.upfronthosting.co.za> Message-ID: <1567002861.09.0.885744918687.issue13824@roundup.psfhosted.org> Change by sebix : ---------- nosy: +sebix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 10:54:51 2019 From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=) Date: Wed, 28 Aug 2019 14:54:51 +0000 Subject: [issue37969] urllib.parse functions reporting false equivalent URIs Message-ID: <1567004091.58.0.0475239472757.issue37969@roundup.psfhosted.org> New submission from G?ry : The Python library documentation of the `urllib.parse.urlunparse `_ and `urllib.parse.urlunsplit `_ functions states: This may result in a slightly different, but equivalent URL, if the URL that was parsed originally had unnecessary delimiters (for example, a ? with an empty query; the RFC states that these are equivalent). So with the URI:: >>> import urllib.parse >>> urllib.parse.urlunparse(urllib.parse.urlparse("http://example.com/?")) 'http://example.com/' >>> urllib.parse.urlunsplit(urllib.parse.urlsplit("http://example.com/?")) 'http://example.com/' But `RFC 3986 `_ states the exact opposite: Normalization should not remove delimiters when their associated component is empty unless licensed to do so by the scheme specification. For example, the URI "http://example.com/?" cannot be assumed to be equivalent to any of the examples above. Likewise, the presence or absence of delimiters within a userinfo subcomponent is usually significant to its interpretation. The fragment component is not subject to any scheme-based normalization; thus, two URIs that differ only by the suffix "#" are considered different regardless of the scheme. So maybe `urllib.parse.urlunparse` ? `urllib.parse.urlparse` and `urllib.parse.urlunsplit` ? `urllib.parse.urlsplit` are not supposed to be used for `syntax-based normalization `_ of URIs. But still, both `urllib.parse.urlparse` or `urllib.parse.urlsplit` lose the "delimiter + empty component" information of the URI string, so they report false equivalent URIs:: >>> import urllib.parse >>> urllib.parse.urlparse("http://example.com/?") == urllib.parse.urlparse("http://example.com/") True >>> urllib.parse.urlsplit("http://example.com/?") == urllib.parse.urlsplit("http://example.com/") True P.-S. ? Is there a syntax-based normalization function of URIs in the Python library? ---------- components: Library (Lib) messages: 350663 nosy: Jeremy.Hylton, maggyero, orsenthil priority: normal severity: normal status: open title: urllib.parse functions reporting false equivalent URIs type: behavior versions: Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 10:59:57 2019 From: report at bugs.python.org (Marco Sulla) Date: Wed, 28 Aug 2019 14:59:57 +0000 Subject: [issue37918] What about an enum for open() modes? In-Reply-To: <1566489249.72.0.0117548525062.issue37918@roundup.psfhosted.org> Message-ID: <1567004397.75.0.731568933805.issue37918@roundup.psfhosted.org> Marco Sulla added the comment: Mh. No one is interested? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 11:23:37 2019 From: report at bugs.python.org (Ned Deily) Date: Wed, 28 Aug 2019 15:23:37 +0000 Subject: [issue37967] release candidate is not gpg signed (and missing release workflow)? In-Reply-To: <1566977917.52.0.520116504637.issue37967@roundup.psfhosted.org> Message-ID: <1567005817.55.0.516929754429.issue37967@roundup.psfhosted.org> Ned Deily added the comment: The description of this issue is incorrect. All the release artifacts for the 3.8.0b3 have GPG signatures available - see https://www.python.org/downloads/release/python-380b3/ - like all other releases. Looking at the log of the failed Travis run in https://github.com/pypa/manylinux/pull/333, the failure there appears to be not finding the release manager's public key to verify the GPG signature against. There is a languishing open issue about the published public keys files having bogus keys in it (https://github.com/python/pythondotorg/issues/1395), perhaps that is related. I'll take a close look shortly. ---------- assignee: -> ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 12:04:22 2019 From: report at bugs.python.org (Nick Timkovich) Date: Wed, 28 Aug 2019 16:04:22 +0000 Subject: [issue37968] The turtle In-Reply-To: <1566997100.11.0.991948132497.issue37968@roundup.psfhosted.org> Message-ID: <1567008262.72.0.849281338901.issue37968@roundup.psfhosted.org> Nick Timkovich added the comment: Regarding #1: In Python, you may refer to a variable's name (e.g. `rt`, which is a function), which often has no effect in a script. In the REPL (where you see >>>) it is useful to inspect the object: >>> turtle.rt In order to call that name/function, parentheses are *required* unlike other languages where they are optional (Ruby). So, you don't get an error message, but one is not expected. Linting tools can alert you to statements that don't appear to have an effect. Regarding #2: Students of the turtle could create a reusable function to draw a circle with the turtle and return to the starting position. It would be an excellent exercise with multiple solutions! ---------- nosy: +nicktimko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 12:12:51 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 Aug 2019 16:12:51 +0000 Subject: [issue37140] ctypes change made clang fail to build In-Reply-To: <1559553697.78.0.201685591504.issue37140@roundup.psfhosted.org> Message-ID: <1567008771.55.0.669059479157.issue37140@roundup.psfhosted.org> STINNER Victor added the comment: Ok, I'm able to reproduce the crash using: git clone https://github.com/llvm/llvm-project.git cd llvm-project mkdir _build cd _build cmake3 ../llvm -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$PWD/install -DPYTHON_EXECUTABLE=$HOME/sources/cpython/_build/install/bin/python3 make -j4 make check-clang-python The crash occurs in the test_access_specifiers() method defined in tests/cindex/test_access_specifiers.py. This test uses ctypes to call functions of the libclang.so dynamic library. I reduced the test case from 4350 lines of Python code to 131 lines of Python which only depends on the standard library and libclang.so. $ cd llvm-project/clang/bindings/python $ wc -l tests/cindex/test_access_specifiers.py tests/cindex/util.py clang/cindex.py 41 tests/cindex/test_access_specifiers.py 90 tests/cindex/util.py 4219 clang/cindex.py 4350 total $ wc -l bug.py 131 bug.py See attached bug.py script. Python 3.7 is fine, whereas Python 3.8 does crash: $ python3.7 bug.py spelling spelling = None _CXString del: obj id=7f0904a6dcb0 spelling = None --- $ python3.8 bug.py spelling spelling = None _CXString del: obj id=7f4fa6180c40 _CXString del: obj id=7f4fa6180ac0 free(): double free detected in tcache 2 Aborted (core dumped) Notice that _CXString.__del__() is only called once in Python 3.7, but called twice in Python 3.8. ---------- Added file: https://bugs.python.org/file48565/bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 12:26:39 2019 From: report at bugs.python.org (Zachary Ware) Date: Wed, 28 Aug 2019 16:26:39 +0000 Subject: [issue37970] urllib.parse docstrings incomplete Message-ID: <1567009599.74.0.471882594509.issue37970@roundup.psfhosted.org> New submission from Zachary Ware : For example, urlsplit: >>> from urllib.parse import urlsplit >>> help(urlsplit) Help on function urlsplit in module urllib.parse: urlsplit(url, scheme='', allow_fragments=True) Parse a URL into 5 components: :///?# Return a 5-tuple: (scheme, netloc, path, query, fragment). Note that we don't break the components up in smaller bits (e.g. netloc is a single string) and we don't expand % escapes. The current docstring does not describe the `scheme` or `allow_fragments` arguments. Also, the note about not splitting netloc is misleading; the components of netloc (username, password, hostname, and port) are available as extra attributes of the returned SplitResult. urlparse has similar issues; other functions could stand to be checked. ---------- assignee: docs at python components: Documentation, Library (Lib) keywords: newcomer friendly messages: 350668 nosy: docs at python, zach.ware priority: normal severity: normal stage: needs patch status: open title: urllib.parse docstrings incomplete versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 12:26:48 2019 From: report at bugs.python.org (Yehuda Katz) Date: Wed, 28 Aug 2019 16:26:48 +0000 Subject: [issue37968] The turtle In-Reply-To: <1567008262.72.0.849281338901.issue37968@roundup.psfhosted.org> Message-ID: Yehuda Katz added the comment: Sorry to say but these don't satisfy my issues. 1 the next code SHOULD produce an error message. Think that it's followed by a few dozens of code lines: from turtle import * fd; rt(90) 2 Old Logo had a useful function of creating a circle AROUND THE TURTLE. It would be very nice it such a function was built-in in turtle module. Giving this to student as a problem is not a good answer, it's more like a sort of "pass the baby" solution. Thank you for the fast reply. Yehuda Katz (Israel) On Wed, Aug 28, 2019 at 7:04 PM Nick Timkovich wrote: > > Nick Timkovich added the comment: > > Regarding #1: In Python, you may refer to a variable's name (e.g. `rt`, > which is a function), which often has no effect in a script. In the REPL > (where you see >>>) it is useful to inspect the object: > > >>> turtle.rt > > > In order to call that name/function, parentheses are *required* unlike > other languages where they are optional (Ruby). So, you don't get an error > message, but one is not expected. Linting tools can alert you to statements > that don't appear to have an effect. > > Regarding #2: Students of the turtle could create a reusable function to > draw a circle with the turtle and return to the starting position. It would > be an excellent exercise with multiple solutions! > > ---------- > nosy: +nicktimko > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 12:29:35 2019 From: report at bugs.python.org (Yehuda Katz) Date: Wed, 28 Aug 2019 16:29:35 +0000 Subject: [issue37968] The turtle In-Reply-To: Message-ID: Yehuda Katz added the comment: Hi, Sorry to say but these don't satisfy my issues. 1 the next code SHOULD produce an error message. Think that it's followed by a few dozens of code lines: from turtle import * fd; rt(90) 2 Old Logo had a useful function of creating a circle AROUND THE TURTLE. It would be very nice it such a function was built-in in Python's turtle module. Giving this to student as a problem is not a good answer, it's more like a sort of "pass the baby" solution. Thank you for the fast reply. On Wed, Aug 28, 2019 at 7:26 PM Yehuda Katz wrote: > > Yehuda Katz added the comment: > > Sorry to say but these don't satisfy my issues. > > 1 the next code SHOULD produce an error message. Think that it's followed > by a few dozens of code lines: > from turtle import * > fd; rt(90) > 2 Old Logo had a useful function of creating a circle AROUND THE TURTLE. It > would be very nice it such a function was built-in in turtle module. > Giving this to student as a problem is not a good answer, it's more like a > sort of "pass the baby" solution. > > Thank you for the fast reply. > > Yehuda Katz (Israel) > > On Wed, Aug 28, 2019 at 7:04 PM Nick Timkovich > wrote: > > > > > Nick Timkovich added the comment: > > > > Regarding #1: In Python, you may refer to a variable's name (e.g. `rt`, > > which is a function), which often has no effect in a script. In the REPL > > (where you see >>>) it is useful to inspect the object: > > > > >>> turtle.rt > > > > > > In order to call that name/function, parentheses are *required* unlike > > other languages where they are optional (Ruby). So, you don't get an > error > > message, but one is not expected. Linting tools can alert you to > statements > > that don't appear to have an effect. > > > > Regarding #2: Students of the turtle could create a reusable function to > > draw a circle with the turtle and return to the starting position. It > would > > be an excellent exercise with multiple solutions! > > > > ---------- > > nosy: +nicktimko > > > > _______________________________________ > > Python tracker > > > > _______________________________________ > > > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 12:32:48 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 28 Aug 2019 16:32:48 +0000 Subject: [issue37878] Sub-Interpreters : Document PyThreadState_DeleteCurrent() In-Reply-To: <1565985235.6.0.212314052144.issue37878@roundup.psfhosted.org> Message-ID: <1567009968.62.0.411249273487.issue37878@roundup.psfhosted.org> Joannah Nanjekye added the comment: I updated the PR to make the function internal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 12:55:17 2019 From: report at bugs.python.org (Nick Timkovich) Date: Wed, 28 Aug 2019 16:55:17 +0000 Subject: [issue37968] The turtle In-Reply-To: <1566997100.11.0.991948132497.issue37968@roundup.psfhosted.org> Message-ID: <1567011317.44.0.578672676996.issue37968@roundup.psfhosted.org> Nick Timkovich added the comment: Resolving #1 as you suggest is next to impossible. Python can not deduce if you meant to call the function or just refer to its name. Admittedly, the latter is strange in non-interactive contexts, but it is valid. #2, as far as I can tell Logo had an ARC command: ARC angle radius draws an arc of a circle, with the turtle at the center, with the specified radius, starting at the turtle's heading and extending clockwise through the specified angle. The turtle does not move. I guess I don't know the history about why there's turtle.circle in Python which *does* move the turtle, and has the center *not* at the turtle. Adding an equivalent "turtle.arc" function might be useful, though the naming would be a bit confusing. Can you propose a better name and define exactly how it would work? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:06:51 2019 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 28 Aug 2019 17:06:51 +0000 Subject: [issue37968] The turtle In-Reply-To: <1566997100.11.0.991948132497.issue37968@roundup.psfhosted.org> Message-ID: <1567012011.13.0.686515302746.issue37968@roundup.psfhosted.org> Mark Dickinson added the comment: > 1 the next code SHOULD produce an error message. Think that it's followed > by a few dozens of code lines: > from turtle import * > fd; rt(90) There's no reasonable mechanism in current Python by which this could produce an error message; it's not an error, and you'd need to make substantial changes to the core language to make it such, including fleshing out exactly what those changes would be and how they'd work, and persuading other core developers that those changes improve the language. As Nick Timkovich points out, tools like pylint will flag this sort of thing. When I run pylint on your script, the output includes the following: > untitled.py:3:8: W0104: Statement seems to have no effect (pointless-statement) If you really want to pursue the necessary changes in the core language, I'd suggest starting a discussion on the python-ideas mailing list; others may have innovative suggestions for ameliorating the core problem. But it's just not feasible in the language as it stands. I'd suggest focusing this issue on your second item, and dropping the first. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:08:26 2019 From: report at bugs.python.org (Yehuda Katz) Date: Wed, 28 Aug 2019 17:08:26 +0000 Subject: [issue37968] The turtle In-Reply-To: <1567011317.44.0.578672676996.issue37968@roundup.psfhosted.org> Message-ID: Yehuda Katz added the comment: Such a function would be welcomed. For the best of my (limited) knowledge, there's currently no arc() function in module turtle. I can't think about a proper name... Sorry. Yehuda On Wed, Aug 28, 2019 at 7:55 PM Nick Timkovich wrote: > > Nick Timkovich added the comment: > > Resolving #1 as you suggest is next to impossible. Python can not deduce > if you meant to call the function or just refer to its name. Admittedly, > the latter is strange in non-interactive contexts, but it is valid. > > #2, as far as I can tell Logo had an ARC command: > > ARC angle radius > > draws an arc of a circle, with the turtle at the center, > with the specified radius, starting at the turtle's > heading and extending clockwise through the specified > angle. The turtle does not move. > > I guess I don't know the history about why there's turtle.circle in Python > which *does* move the turtle, and has the center *not* at the turtle. > Adding an equivalent "turtle.arc" function might be useful, though the > naming would be a bit confusing. Can you propose a better name and define > exactly how it would work? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:10:12 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 28 Aug 2019 17:10:12 +0000 Subject: [issue27260] Missing equality check for super objects In-Reply-To: <1465332483.31.0.223891907563.issue27260@psf.upfronthosting.co.za> Message-ID: <1567012212.93.0.994026856295.issue27260@roundup.psfhosted.org> Raymond Hettinger added the comment: Though not beautiful, we already have a way to fulfill this rare use case: >>> class Foo(): pass >>> s = super(Foo) >>> t = super(Foo) >>> (s.__self_class__, s.__self__) == (t.__self_class__, t.__self__) >>> True Though awkward to write, it is completely explicit. That makes it better than giving "s == t" a profoundly different meaning than "s.__eq__(t)". IMO that would be an API mistake, making it tricky to do code review and requiring special knowledge of a rare corner case. ---------- resolution: -> rejected stage: -> resolved status: open -> closed versions: +Python 3.9 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:11:12 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 28 Aug 2019 17:11:12 +0000 Subject: [issue37965] CCompiler has_function displays warning In-Reply-To: <1566938834.78.0.244631078662.issue37965@roundup.psfhosted.org> Message-ID: <1567012272.18.0.0914379370147.issue37965@roundup.psfhosted.org> miss-islington added the comment: New changeset 55aabee07501e1468082b3237620e4ecd75c5da6 by Miss Islington (bot) (Anonymous Maarten) in branch 'master': closes bpo-37965: Fix compiler warning of distutils CCompiler.test_function. (GH-15560) https://github.com/python/cpython/commit/55aabee07501e1468082b3237620e4ecd75c5da6 ---------- nosy: +miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:11:25 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 28 Aug 2019 17:11:25 +0000 Subject: [issue37965] CCompiler has_function displays warning In-Reply-To: <1566938834.78.0.244631078662.issue37965@roundup.psfhosted.org> Message-ID: <1567012285.47.0.506196684517.issue37965@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15236 pull_request: https://github.com/python/cpython/pull/15561 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:11:32 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 28 Aug 2019 17:11:32 +0000 Subject: [issue37965] CCompiler has_function displays warning In-Reply-To: <1566938834.78.0.244631078662.issue37965@roundup.psfhosted.org> Message-ID: <1567012292.35.0.324154899951.issue37965@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15237 pull_request: https://github.com/python/cpython/pull/15562 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:11:40 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 28 Aug 2019 17:11:40 +0000 Subject: [issue37965] CCompiler has_function displays warning In-Reply-To: <1566938834.78.0.244631078662.issue37965@roundup.psfhosted.org> Message-ID: <1567012300.82.0.530933136102.issue37965@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15238 pull_request: https://github.com/python/cpython/pull/15563 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:13:35 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Wed, 28 Aug 2019 17:13:35 +0000 Subject: [issue20806] os.times document points to wrong section of non-Linux manual In-Reply-To: <1393590805.13.0.860460942185.issue20806@psf.upfronthosting.co.za> Message-ID: <1567012415.85.0.0534137836226.issue20806@roundup.psfhosted.org> Joannah Nanjekye added the comment: I updated the PR to reference times(2) and times(3) along with an MSDN link. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:29:34 2019 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 28 Aug 2019 17:29:34 +0000 Subject: [issue37968] Add a turtle module function to draw a circle centered at the turtle In-Reply-To: <1566997100.11.0.991948132497.issue37968@roundup.psfhosted.org> Message-ID: <1567013374.68.0.367177304272.issue37968@roundup.psfhosted.org> Mark Dickinson added the comment: Updated title, type and Python version (this would be a new feature, so would be targeted at Python 3.9). ---------- components: +Library (Lib) title: The turtle -> Add a turtle module function to draw a circle centered at the turtle type: -> enhancement versions: +Python 3.9 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:31:45 2019 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 28 Aug 2019 17:31:45 +0000 Subject: [issue37968] Add a turtle module function to draw a circle centered at the turtle In-Reply-To: <1566997100.11.0.991948132497.issue37968@roundup.psfhosted.org> Message-ID: <1567013505.14.0.720658433859.issue37968@roundup.psfhosted.org> Change by Mark Dickinson : ---------- nosy: +glingl, willingc -mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:32:38 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 28 Aug 2019 17:32:38 +0000 Subject: [issue37965] CCompiler has_function displays warning In-Reply-To: <1566938834.78.0.244631078662.issue37965@roundup.psfhosted.org> Message-ID: <1567013558.04.0.795398555349.issue37965@roundup.psfhosted.org> Benjamin Peterson added the comment: New changeset 23985c6a64222df46cd7e21b9b21c0e37aa95e10 by Benjamin Peterson (Miss Islington (bot)) in branch '3.8': closes bpo-37965: Fix compiler warning of distutils CCompiler.test_function. (GH-15561) https://github.com/python/cpython/commit/23985c6a64222df46cd7e21b9b21c0e37aa95e10 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:36:21 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 28 Aug 2019 17:36:21 +0000 Subject: [issue37965] CCompiler has_function displays warning In-Reply-To: <1566938834.78.0.244631078662.issue37965@roundup.psfhosted.org> Message-ID: <1567013781.03.0.444362379362.issue37965@roundup.psfhosted.org> miss-islington added the comment: New changeset 0229b56d8c0cb65b8ad789e69dcd281fd92a6d96 by Miss Islington (bot) in branch '2.7': closes bpo-37965: Fix compiler warning of distutils CCompiler.test_function. (GH-15560) https://github.com/python/cpython/commit/0229b56d8c0cb65b8ad789e69dcd281fd92a6d96 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:37:41 2019 From: report at bugs.python.org (miss-islington) Date: Wed, 28 Aug 2019 17:37:41 +0000 Subject: [issue37965] CCompiler has_function displays warning In-Reply-To: <1566938834.78.0.244631078662.issue37965@roundup.psfhosted.org> Message-ID: <1567013861.02.0.522034175844.issue37965@roundup.psfhosted.org> miss-islington added the comment: New changeset ea48966e5d868e2863d896ee909460d482a0513c by Miss Islington (bot) in branch '3.7': closes bpo-37965: Fix compiler warning of distutils CCompiler.test_function. (GH-15560) https://github.com/python/cpython/commit/ea48966e5d868e2863d896ee909460d482a0513c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 13:56:08 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 28 Aug 2019 17:56:08 +0000 Subject: [issue23674] super() documentation isn't very clear In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za> Message-ID: <1567014968.2.0.0992873342291.issue23674@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +15239 pull_request: https://github.com/python/cpython/pull/15564 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 14:02:42 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 28 Aug 2019 18:02:42 +0000 Subject: [issue37176] super() docs don't say what super() does In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org> Message-ID: <1567015362.53.0.931068290955.issue37176@roundup.psfhosted.org> Raymond Hettinger added the comment: I've add PR 15564 to clarify some known ambiguities for the super() docs including a specific example "what it actually does". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 14:08:16 2019 From: report at bugs.python.org (Yehuda Katz) Date: Wed, 28 Aug 2019 18:08:16 +0000 Subject: [issue37968] Add a turtle module function to draw a circle centered at the turtle In-Reply-To: <1567013374.68.0.367177304272.issue37968@roundup.psfhosted.org> Message-ID: Yehuda Katz added the comment: G-R-E-A-T. Yehuda, Israel On Wed, Aug 28, 2019 at 8:29 PM Mark Dickinson wrote: > > Mark Dickinson added the comment: > > Updated title, type and Python version (this would be a new feature, so > would be targeted at Python 3.9). > > ---------- > components: +Library (Lib) > title: The turtle -> Add a turtle module function to draw a circle > centered at the turtle > type: -> enhancement > versions: +Python 3.9 -Python 3.7 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 14:09:52 2019 From: report at bugs.python.org (Yehuda Katz) Date: Wed, 28 Aug 2019 18:09:52 +0000 Subject: [issue37968] Add a turtle module function to draw a circle centered at the turtle In-Reply-To: <1567013374.68.0.367177304272.issue37968@roundup.psfhosted.org> Message-ID: Yehuda Katz added the comment: G-R-E-A-T. Yehuda (Israel) On Wed, Aug 28, 2019 at 8:29 PM Mark Dickinson wrote: > > Mark Dickinson added the comment: > > Updated title, type and Python version (this would be a new feature, so > would be targeted at Python 3.9). > > ---------- > components: +Library (Lib) > title: The turtle -> Add a turtle module function to draw a circle > centered at the turtle > type: -> enhancement > versions: +Python 3.9 -Python 3.7 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 14:23:20 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 28 Aug 2019 18:23:20 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1567016600.75.0.523770079662.issue15206@roundup.psfhosted.org> Raymond Hettinger added the comment: The random number generator now reseeds after a fork. Can this now be closed as "out-of-date" or is there still something that needs to be done? ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 14:32:52 2019 From: report at bugs.python.org (Joran van Apeldoorn) Date: Wed, 28 Aug 2019 18:32:52 +0000 Subject: [issue37971] Wrong trace with multiple decorators (linenumber wrong in frame) Message-ID: <1567017172.25.0.486267767179.issue37971@roundup.psfhosted.org> New submission from Joran van Apeldoorn : When applying multiple decorators to a function, a traceback from the top generator shows the bottom generator instead. For example ---------------- def printingdec(f): raise Exception() return f def dummydec(f): return f @printingdec @dummydec def foo(): pass ---------------- gives Traceback (most recent call last): File "bug.py", line 9, in @dummydec File "bug.py", line 2, in printingdec raise Exception() Exception instead of Traceback (most recent call last): File "bug.py", line 8, in @printingdec File "bug.py", line 2, in printingdec raise Exception() Exception Digging around with sys._getframe() it seems that the frame's linenumber is set wrong internally, leading to the wrong line being displayed. The ast does display the correct linenumber. ---------- messages: 350686 nosy: control-k priority: normal severity: normal status: open title: Wrong trace with multiple decorators (linenumber wrong in frame) type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 14:59:13 2019 From: report at bugs.python.org (Nick Timkovich) Date: Wed, 28 Aug 2019 18:59:13 +0000 Subject: [issue37969] urllib.parse functions reporting false equivalent URIs In-Reply-To: <1567004091.58.0.0475239472757.issue37969@roundup.psfhosted.org> Message-ID: <1567018753.72.0.988034942926.issue37969@roundup.psfhosted.org> Nick Timkovich added the comment: Looking at the history, the line in the docs used to say > ... (for example, an empty query (the draft states that these are equivalent). which was changed to "the RFC" in April 2006 https://github.com/python/cpython/commit/ad5177cf8da#diff-5b4cef771c997754f9e2feeae11d3b1eL68-R95 The original language was added in February 1995 https://github.com/python/cpython/commit/a12ef9433baf#diff-5b4cef771c997754f9e2feeae11d3b1eR48-R51 So "the draft" probably meant the draft of RFC-1738 https://tools.ietf.org/html/rfc1738#section-3.3 which is kinda vague on it. It didn't help that rewording it as "the RFC" later when there are 3+ RFCs referenced in the lib docs, one of which obsoleted the another RFC and definitely changed the meaning of the loose "?". The draft of 2396 always seemed to have the opposite wording you point out, at least back in draft 07 (September 2004): https://tools.ietf.org/html/draft-fielding-uri-rfc2396bis-07#section-6.2.3 The draft 06 (April 2004) was silent on the matter https://tools.ietf.org/html/draft-fielding-uri-rfc2396bis-06#section-6.2.3 ---------- nosy: +nicktimko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 16:33:01 2019 From: report at bugs.python.org (blhsing) Date: Wed, 28 Aug 2019 20:33:01 +0000 Subject: [issue37972] unittest.mock.call does not chain __getitem__ to another _Call object Message-ID: <1567024381.55.0.529292089661.issue37972@roundup.psfhosted.org> New submission from blhsing : As reported on StackOverflow: https://stackoverflow.com/questions/57636747/how-to-perform-assert-has-calls-for-a-getitem-call The following code would output: [call(), call().foo(), call().foo().__getitem__('bar')] from unittest.mock import MagicMock, call mm = MagicMock() mm().foo()['bar'] print(mm.mock_calls) but trying to use that list with mm.assert_has_calls([call(), call().foo(), call().foo().__getitem__('bar')]) would result in: TypeError: tuple indices must be integers or slices, not str ---------- components: Library (Lib) messages: 350688 nosy: Ben Hsing priority: normal severity: normal status: open title: unittest.mock.call does not chain __getitem__ to another _Call object type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 16:58:09 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Wed, 28 Aug 2019 20:58:09 +0000 Subject: [issue37972] unittest.mock.call does not chain __getitem__ to another _Call object In-Reply-To: <1567024381.55.0.529292089661.issue37972@roundup.psfhosted.org> Message-ID: <1567025889.32.0.780820901669.issue37972@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 17:17:21 2019 From: report at bugs.python.org (Ben Hsing) Date: Wed, 28 Aug 2019 21:17:21 +0000 Subject: [issue37972] unittest.mock.call does not chain __getitem__ to another _Call object In-Reply-To: <1567024381.55.0.529292089661.issue37972@roundup.psfhosted.org> Message-ID: <1567027041.83.0.240998213139.issue37972@roundup.psfhosted.org> Change by Ben Hsing : ---------- keywords: +patch pull_requests: +15240 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15565 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 17:54:08 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 Aug 2019 21:54:08 +0000 Subject: [issue23878] Missing sanity checks for various C library function calls... In-Reply-To: <1428339627.31.0.628073381935.issue23878@psf.upfronthosting.co.za> Message-ID: <1567029248.11.0.0517599619387.issue23878@roundup.psfhosted.org> STINNER Victor added the comment: New changeset e4a5e9b5bb69025eb879cb133259667241d61a1f by Victor Stinner (Zackery Spytz) in branch 'master': bpo-23878: Remove an unneeded fseek() call in _Py_FindEnvConfigValue() (GH-15424) https://github.com/python/cpython/commit/e4a5e9b5bb69025eb879cb133259667241d61a1f ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 17:59:13 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 Aug 2019 21:59:13 +0000 Subject: [issue23878] Missing sanity checks for various C library function calls... In-Reply-To: <1428339627.31.0.628073381935.issue23878@psf.upfronthosting.co.za> Message-ID: <1567029553.87.0.798809462435.issue23878@roundup.psfhosted.org> STINNER Victor added the comment: The fseek() call has been removed from _Py_FindEnvConfigValue (previously in getpath.c). There is a single file called ffi.c in the master branch: ./Modules/_ctypes/libffi_osx/ffi.c And this file doesn't call calloc(). I guess that the bug was in our embedded copy of libffi (Modules/_ctypes/libffi/src/arm/ffi has been removed). Copy which has been removed in the meanwhile. If someone cares, check if all calloc() calls are checked for failure in https://sourceware.org/libffi/ >From the Python point of view, all bugs described in this issue are now fixed. Thanks for the report and thanks for the fix ;-) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 2.7, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 18:01:27 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 28 Aug 2019 22:01:27 +0000 Subject: [issue37971] Wrong trace with multiple decorators (linenumber wrong in frame) In-Reply-To: <1567017172.25.0.486267767179.issue37971@roundup.psfhosted.org> Message-ID: <1567029687.79.0.0554391929538.issue37971@roundup.psfhosted.org> Serhiy Storchaka added the comment: In Python 3.8+ I got: Traceback (most recent call last): File "/home/serhiy/py/cpython/issue37971.py", line 10, in def foo(): File "/home/serhiy/py/cpython/issue37971.py", line 2, in printingdec raise Exception() Exception The traceback refers to the line where the function is defined. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 18:02:08 2019 From: report at bugs.python.org (Zackery Spytz) Date: Wed, 28 Aug 2019 22:02:08 +0000 Subject: [issue23878] Missing sanity checks for various C library function calls... In-Reply-To: <1428339627.31.0.628073381935.issue23878@psf.upfronthosting.co.za> Message-ID: <1567029728.52.0.881828298531.issue23878@roundup.psfhosted.org> Change by Zackery Spytz : ---------- pull_requests: +15241 pull_request: https://github.com/python/cpython/pull/15555 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 18:19:43 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 Aug 2019 22:19:43 +0000 Subject: [issue15206] uuid module falls back to unsuitable RNG In-Reply-To: <1340805699.85.0.817571094699.issue15206@psf.upfronthosting.co.za> Message-ID: <1567030783.37.0.00510592948716.issue15206@roundup.psfhosted.org> STINNER Victor added the comment: I close the issue. Python 3.7 and newer are fixed. Python 2.7 is still affected, but I consider that it's ok to leave the bug unfixed in this version. -- > The random number generator now reseeds after a fork. I confirm that it's done since Python 3.7, and Python 3.6 doesn't accept bugfixes anymore (only security fixes). So the issue is fixed in Python 3.7, 3.8 and master. For the record, the fix was this change: commit 346cbd351ee0dd3ab9cb9f0e4cb625556707877e Author: Antoine Pitrou Date: Sat May 27 17:50:54 2017 +0200 bpo-16500: Allow registering at-fork handlers (#1715) Backporting this change to Python 3.6 and 3.5 would be too intrusive and risky. I don't think that this bug is important enough to be qualified as security vulnerability (the issue type is not "Security"). For Python 2.7, honestly, I don't think that the issue matters enough to justify to fix it today, knowning that Python 2.7 will reach its end of life at the end of the year. Moreover, apart Christian Heimes, no user ever complained about this issue. Note: uuid.uuid4() always used os.urandom(16) which is not affected by this issue on fork. Only uuid.uuid1() and uuid.getnode() has the bug in Python 2.7. ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.7, Python 3.8, Python 3.9 -Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 19:23:11 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 28 Aug 2019 23:23:11 +0000 Subject: [issue37968] Add a turtle module function to draw a circle centered at the turtle In-Reply-To: <1566997100.11.0.991948132497.issue37968@roundup.psfhosted.org> Message-ID: <1567034591.98.0.0258107755515.issue37968@roundup.psfhosted.org> Raymond Hettinger added the comment: > For the best of my (limited) knowledge, there's currently > no arc() function in module turtle. circle() takes a second argument called "extent": circle(200, 90) # draw 90? of a circle of radius 200 FWIW, searching the turtle documentation page for "arc" immediately finds the two argument form of circle, so I don't think there is a discoverability problem. Suggestion for Yehuda: Consider driving the turtle module from IPython. It has an "%autocall" mode that automatically adds parentheses. For example: forward 100 right 90 gets automatically transformed to: forward(100) right(90) FWIW, I concur with Nick that we shouldn't add a new circle function centered on the turtle. He was correct that this would make a great exercise. More importantly, making the module bigger doesn't make it easier to use (see https://en.wikipedia.org/wiki/Overchoice ). You've already indicated that you don't yet know the full API and haven't found essential tools like the two argument form of circle(), so making the API bigger would likely have made the discoverability problem worse. At this point, I think we should close this tracker issue: * It's not easily possible to make "rt" generate an error message * Circle centered on a turtle is best left as an exercise * arc() is already present in the two argument form of circle() One other thought: The Python API was based on other turtle implementations, so the API is probably mostly already where it should be. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 19:24:10 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 28 Aug 2019 23:24:10 +0000 Subject: [issue37968] Add a turtle module function to draw a circle centered at the turtle In-Reply-To: <1566997100.11.0.991948132497.issue37968@roundup.psfhosted.org> Message-ID: <1567034650.21.0.636160771383.issue37968@roundup.psfhosted.org> Raymond Hettinger added the comment: Also see: https://en.wikipedia.org/wiki/The_Paradox_of_Choice ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 19:43:44 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 Aug 2019 23:43:44 +0000 Subject: [issue37959] test_os.test_copy_file_range() killed by SIGSYS (12) on FreeBSD CURRENT buildbot In-Reply-To: <1566889155.63.0.559202876423.issue37959@roundup.psfhosted.org> Message-ID: <1567035824.14.0.319652350747.issue37959@roundup.psfhosted.org> STINNER Victor added the comment: AMD64 FreeBSD CURRENT Shared 3.x is back to green. I close the issue. https://buildbot.python.org/all/#/builders/168/builds/1356 likely failed because kkobs upgrade the FreeBSD CURRENT VM while the buildbot job was running (inconsistency between *running* libc and kernel, I guess). ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 19:46:16 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 Aug 2019 23:46:16 +0000 Subject: [issue37385] test_multiprocessing fails on AMD64 FreeBSD CURRENT Shared 2.7 In-Reply-To: <1561375719.2.0.947159095259.issue37385@roundup.psfhosted.org> Message-ID: <1567035976.34.0.695566392473.issue37385@roundup.psfhosted.org> STINNER Victor added the comment: AMD64 FreeBSD CURRENT Shared 2.7 is back to green: this issue is a duplicate of bpo-28724 that I fixed recently. ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Add method send_io, recv_io to the socket module. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 19:57:11 2019 From: report at bugs.python.org (STINNER Victor) Date: Wed, 28 Aug 2019 23:57:11 +0000 Subject: [issue37918] What about an enum for open() modes? In-Reply-To: <1566489249.72.0.0117548525062.issue37918@roundup.psfhosted.org> Message-ID: <1567036631.39.0.06762563727.issue37918@roundup.psfhosted.org> STINNER Victor added the comment: Please send an email to the python-ideas mailing list, rather than opening a bug report at bugs.python.org. ---------- nosy: +vstinner resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 20:13:30 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Aug 2019 00:13:30 +0000 Subject: [issue33955] Implement PyOS_CheckStack on macOS using pthread_get_stack*_np In-Reply-To: <1529925495.69.0.56676864532.issue33955@psf.upfronthosting.co.za> Message-ID: <1567037610.0.0.381974107515.issue33955@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 20:22:42 2019 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 29 Aug 2019 00:22:42 +0000 Subject: [issue37968] Add a turtle module function to draw a circle centered at the turtle In-Reply-To: <1566997100.11.0.991948132497.issue37968@roundup.psfhosted.org> Message-ID: <1567038162.61.0.463841262505.issue37968@roundup.psfhosted.org> Eric V. Smith added the comment: I agree that we should close this and not implement a function to draw a circle centered on the turtle. The fundamental abstraction with turtle graphics is that the turtle is holding a pen. To have the pen draw elsewhere, where the turtle does not go, breaks the abstraction. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 20:36:09 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 00:36:09 +0000 Subject: [issue37968] Add a turtle module function to draw a circle centered at the turtle In-Reply-To: <1566997100.11.0.991948132497.issue37968@roundup.psfhosted.org> Message-ID: <1567038969.22.0.471992453823.issue37968@roundup.psfhosted.org> Raymond Hettinger added the comment: Yehuda, thank you for the suggestions, but we're going to decline. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 21:05:26 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 01:05:26 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1567040726.36.0.162433024127.issue16468@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +15242 pull_request: https://github.com/python/cpython/pull/15566 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 21:56:22 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 01:56:22 +0000 Subject: [issue37964] F_GETPATH is not available in fcntl.fcntl In-Reply-To: <1566917599.68.0.248827592945.issue37964@roundup.psfhosted.org> Message-ID: <1567043782.68.0.195694071258.issue37964@roundup.psfhosted.org> miss-islington added the comment: New changeset 13f37f2ba8b1fa39f312dca920e847d9c0313c77 by Miss Islington (bot) (Vinay Sharma) in branch 'master': closes bpo-37964: add F_GETPATH command to fcntl (GH-15550) https://github.com/python/cpython/commit/13f37f2ba8b1fa39f312dca920e847d9c0313c77 ---------- nosy: +miss-islington resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 22:01:31 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 29 Aug 2019 02:01:31 +0000 Subject: [issue37428] SSLContext.post_handshake_auth implicitly enables cert validation In-Reply-To: <1561631609.42.0.922673247425.issue37428@roundup.psfhosted.org> Message-ID: <1567044091.68.0.978791177529.issue37428@roundup.psfhosted.org> Benjamin Peterson added the comment: Yes, please. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 22:03:54 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 29 Aug 2019 02:03:54 +0000 Subject: [issue37440] httplib should enable post-handshake authentication for TLS 1.3 In-Reply-To: <1561732145.9.0.0353203933987.issue37440@roundup.psfhosted.org> Message-ID: <1567044234.03.0.406510964185.issue37440@roundup.psfhosted.org> Benjamin Peterson added the comment: Yes, makes sense for 2.7, too. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 22:32:44 2019 From: report at bugs.python.org (hongweipeng) Date: Thu, 29 Aug 2019 02:32:44 +0000 Subject: [issue34410] itertools.tee not thread-safe; can segfault interpreter when wrapped iterator releases GIL In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za> Message-ID: <1567045964.69.0.258527799697.issue34410@roundup.psfhosted.org> Change by hongweipeng : ---------- pull_requests: +15243 pull_request: https://github.com/python/cpython/pull/15567 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 23:16:57 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 29 Aug 2019 03:16:57 +0000 Subject: [issue37973] improve docstrings of sys.float_info Message-ID: <1567048617.81.0.748558704563.issue37973@roundup.psfhosted.org> New submission from Sergey Fedoseev : In [8]: help(sys.float_info) ... | | dig | DBL_DIG -- digits | This is not very helpful, https://docs.python.org/3/library/sys.html#sys.float_info is more verbose, so probably docstrings should be updated from where. ---------- assignee: docs at python components: Documentation messages: 350703 nosy: docs at python, sir-sigurd priority: normal severity: normal status: open title: improve docstrings of sys.float_info type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 23:30:45 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 29 Aug 2019 03:30:45 +0000 Subject: [issue37974] zip() docstring should say 'iterator' instead of 'object with __next__()' Message-ID: <1567049445.71.0.232910822835.issue37974@roundup.psfhosted.org> New submission from Sergey Fedoseev : In [3]: help(zip) class zip(object) | zip(*iterables) --> zip object | | Return a zip object whose .__next__() method returns a tuple where | the i-th element comes from the i-th iterable argument. The .__next__() | method continues until the shortest iterable in the argument sequence | is exhausted and then it raises StopIteration. This description is awkward and should use term 'iterator' as https://docs.python.org/3/library/functions.html#zip does. The same applies to chain(), count() and zip_longest() from itertools. ---------- assignee: docs at python components: Documentation messages: 350704 nosy: docs at python, sir-sigurd priority: normal severity: normal status: open title: zip() docstring should say 'iterator' instead of 'object with __next__()' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Aug 28 23:43:14 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 03:43:14 +0000 Subject: [issue34410] itertools.tee not thread-safe; can segfault interpreter when wrapped iterator releases GIL In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za> Message-ID: <1567050194.55.0.492633404294.issue34410@roundup.psfhosted.org> Raymond Hettinger added the comment: I've applied the patch to "master". I considered backporting but am thinking that would be risky at this stage in the 3.8 release. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 -Python 2.7, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 00:28:20 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 29 Aug 2019 04:28:20 +0000 Subject: [issue37964] F_GETPATH is not available in fcntl.fcntl In-Reply-To: <1566917599.68.0.248827592945.issue37964@roundup.psfhosted.org> Message-ID: <1567052900.04.0.963172241721.issue37964@roundup.psfhosted.org> Change by Benjamin Peterson : ---------- pull_requests: +15244 pull_request: https://github.com/python/cpython/pull/15568 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 00:33:55 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 04:33:55 +0000 Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za> Message-ID: <1567053235.37.0.478472767955.issue18378@roundup.psfhosted.org> Ned Deily added the comment: New changeset b0caf329815120acf50287e29858093d328b0e3c by Ned Deily (Ronald Oussoren) in branch 'master': bpo-18378: Recognize "UTF-8" as a valid name in locale._parse_localename (GH-14736) https://github.com/python/cpython/commit/b0caf329815120acf50287e29858093d328b0e3c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 00:34:09 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 04:34:09 +0000 Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za> Message-ID: <1567053249.26.0.217019311619.issue18378@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15245 pull_request: https://github.com/python/cpython/pull/15569 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 00:34:15 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 04:34:15 +0000 Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za> Message-ID: <1567053255.89.0.13469859937.issue18378@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15246 pull_request: https://github.com/python/cpython/pull/15570 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 00:47:19 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 04:47:19 +0000 Subject: [issue37482] Email address display name fails with both encoded words and special chars In-Reply-To: <1562068275.57.0.247896906946.issue37482@roundup.psfhosted.org> Message-ID: <1567054039.52.0.908453238901.issue37482@roundup.psfhosted.org> Ned Deily added the comment: New changeset bd127b1b7dd50c76c4419d9c87c12901527d19da by Ned Deily (bsiem) in branch '3.8': [3.8] bpo-37482: Fix email address name with encoded words and special chars (GH-14561) (GH-15380) https://github.com/python/cpython/commit/bd127b1b7dd50c76c4419d9c87c12901527d19da ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 00:51:58 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 04:51:58 +0000 Subject: [issue36743] Docs: Descript __get__ signature defined differently across the docs In-Reply-To: <1556387803.45.0.177981206888.issue36743@roundup.psfhosted.org> Message-ID: <1567054318.94.0.727992928146.issue36743@roundup.psfhosted.org> Raymond Hettinger added the comment: Collecting various factlets on this topic PEP 252 gives the specification for the descriptor protocol: "__get__(): a function callable with one or two arguments that retrieves the attribute value from an object." function_get, property_get, classmethod_get, and staticmethod_get all support calls with one or two arguments: >>> a = A() >>> class A: def m(self): return 42 @property def p(self): return 43 @classmethod def c(cls): return 44 @staticmethod def s(): return 45 >>> a = A() >>> vars(A)['m'].__get__(a)() 42 >>> vars(A)['m'].__get__(a, A)() 42 >>> vars(A)['p'].__get__(a) 43 >>> vars(A)['p'].__get__(a, A) 43 >>> vars(A)['c'].__get__(a)() 44 >>> vars(A)['c'].__get__(a, A)() 44 >>> vars(A)['s'].__get__(a)() 45 >>> vars(A)['s'].__get__(a, A)() 45 Python functions that comply with the specification should also do the same (as taught by the descriptor HOWTO). That said, I have found multiple Python functions that aren't providing the None default. I will fix those as I find them. type.__getattribute__, object.__getattribute__ and super.__getattribute__ always call __get__ with both attributes specified: >>> class D: def __get__(*args): print(args) >>> class C: d = D() >>> class S(C): def f(self): return super().d >>> C.d (<__main__.D object at 0x104d967f0>, None, ) >>> C().d (<__main__.D object at 0x104d967f0>, <__main__.C object at 0x104df77c0>, ) >>> S().f() (<__main__.D object at 0x104d967f0>, <__main__.S object at 0x104df7580>, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 00:52:45 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 04:52:45 +0000 Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za> Message-ID: <1567054365.81.0.842260468895.issue18378@roundup.psfhosted.org> miss-islington added the comment: New changeset 554143ebc2546e0b8b722dfafe397c0316f29980 by Miss Islington (bot) in branch '3.7': bpo-18378: Recognize "UTF-8" as a valid name in locale._parse_localename (GH-14736) https://github.com/python/cpython/commit/554143ebc2546e0b8b722dfafe397c0316f29980 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 00:53:14 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 04:53:14 +0000 Subject: [issue36511] Add Windows ARM32 buildbot In-Reply-To: <1554232161.58.0.393661272603.issue36511@roundup.psfhosted.org> Message-ID: <1567054394.48.0.723371772268.issue36511@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15247 pull_request: https://github.com/python/cpython/pull/15571 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 00:56:03 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 04:56:03 +0000 Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za> Message-ID: <1567054563.24.0.948571750604.issue18378@roundup.psfhosted.org> miss-islington added the comment: New changeset e471a543a4f7c52a8d0081ec5142adab3416d8fb by Miss Islington (bot) in branch '3.8': bpo-18378: Recognize "UTF-8" as a valid name in locale._parse_localename (GH-14736) https://github.com/python/cpython/commit/e471a543a4f7c52a8d0081ec5142adab3416d8fb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 00:58:57 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 04:58:57 +0000 Subject: [issue37482] Email address display name fails with both encoded words and special chars In-Reply-To: <1562068275.57.0.247896906946.issue37482@roundup.psfhosted.org> Message-ID: <1567054737.14.0.447269342032.issue37482@roundup.psfhosted.org> Ned Deily added the comment: I manually merged the stalled 3.8 backport to make 3.8.0b4. Can this issue now be closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:06:03 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 05:06:03 +0000 Subject: [issue34775] pathlib.PurePath division raises TypeError instead of returning NotImplemented In-Reply-To: <1537686128.89.0.956365154283.issue34775@psf.upfronthosting.co.za> Message-ID: <1567055163.35.0.771042263224.issue34775@roundup.psfhosted.org> Ned Deily added the comment: New changeset 4adcaf81513e57a2a4e278073a89efb1375af8df by Ned Deily (Miss Islington (bot)) in branch '3.8': bpo-34775: Return NotImplemented in PurePath division. (GH-9509) (GH-15172) https://github.com/python/cpython/commit/4adcaf81513e57a2a4e278073a89efb1375af8df ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:06:52 2019 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 29 Aug 2019 05:06:52 +0000 Subject: [issue37964] F_GETPATH is not available in fcntl.fcntl In-Reply-To: <1566917599.68.0.248827592945.issue37964@roundup.psfhosted.org> Message-ID: <1567055212.27.0.278802799849.issue37964@roundup.psfhosted.org> Benjamin Peterson added the comment: New changeset 465e5d5bcbfd42be058d3584ccb421405eba1594 by Benjamin Peterson in branch 'master': bpo-37964: Make sure test works if TESTFN is in a non-ASCII directory. (GH-15568) https://github.com/python/cpython/commit/465e5d5bcbfd42be058d3584ccb421405eba1594 ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:12:34 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 05:12:34 +0000 Subject: [issue34775] pathlib.PurePath division raises TypeError instead of returning NotImplemented In-Reply-To: <1537686128.89.0.956365154283.issue34775@psf.upfronthosting.co.za> Message-ID: <1567055554.3.0.407726724425.issue34775@roundup.psfhosted.org> Ned Deily added the comment: The change was pushed for release in 3.8.0b4. I don't think we should backport it to 3.7 at this stage in its lifecycle as the old behavior has been around for a long time. Thanks, everyone! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 -Python 3.6, Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:17:25 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 05:17:25 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1567055845.56.0.336086313378.issue18049@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15248 pull_request: https://github.com/python/cpython/pull/15572 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:18:18 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 05:18:18 +0000 Subject: [issue36511] Add Windows ARM32 buildbot In-Reply-To: <1554232161.58.0.393661272603.issue36511@roundup.psfhosted.org> Message-ID: <1567055898.72.0.701017477692.issue36511@roundup.psfhosted.org> miss-islington added the comment: New changeset ed00fee7d4c28489b5d6e4580b1e1fe0855687ca by Miss Islington (bot) in branch '3.8': bpo-36511: Fix failures in Windows ARM32 buildbot (GH-15181) https://github.com/python/cpython/commit/ed00fee7d4c28489b5d6e4580b1e1fe0855687ca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:23:07 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 05:23:07 +0000 Subject: [issue25777] Misleading descriptions in docs about invoking descriptors. In-Reply-To: <1449058941.53.0.26351823319.issue25777@psf.upfronthosting.co.za> Message-ID: <1567056187.42.0.696191539034.issue25777@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- keywords: +patch pull_requests: +15249 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15573 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:24:26 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 05:24:26 +0000 Subject: [issue36511] Add Windows ARM32 buildbot In-Reply-To: <1554232161.58.0.393661272603.issue36511@roundup.psfhosted.org> Message-ID: <1567056266.23.0.486430601023.issue36511@roundup.psfhosted.org> Ned Deily added the comment: I manually restarted and merged the stalled 3.8 backport for 3.8.0b4. Can this issue now be closed? ---------- nosy: +ned.deily versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:30:32 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 05:30:32 +0000 Subject: [issue36511] Add Windows ARM32 buildbot In-Reply-To: <1554232161.58.0.393661272603.issue36511@roundup.psfhosted.org> Message-ID: <1567056632.97.0.421952885466.issue36511@roundup.psfhosted.org> Ned Deily added the comment: > Can this issue now be closed? I spoke too soon. It appears there's another open backport PR-14244 for this issue that needs some conflict resolution to be merged. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:35:44 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 05:35:44 +0000 Subject: [issue18049] Re-enable threading test on macOS In-Reply-To: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> Message-ID: <1567056944.3.0.211476857115.issue18049@roundup.psfhosted.org> miss-islington added the comment: New changeset f92bb6ed336c49cabf30717c3b741b1b4284f491 by Miss Islington (bot) in branch '3.8': bpo-18049: Define THREAD_STACK_SIZE for AIX to pass default recursion limit test (GH-15081) https://github.com/python/cpython/commit/f92bb6ed336c49cabf30717c3b741b1b4284f491 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:40:53 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 05:40:53 +0000 Subject: [issue36167] DOC: Incorrect capitalization in Programming FAQ In-Reply-To: <1551529099.5.0.835675772758.issue36167@roundup.psfhosted.org> Message-ID: <1567057253.38.0.40492171652.issue36167@roundup.psfhosted.org> Ned Deily added the comment: New changeset 3aa48b88c7485aca1fdfa54b3d8e53931ff067fd by Ned Deily (avinassh) in branch 'master': bpo-36167: fix an incorrect capitalization (GH-14482) https://github.com/python/cpython/commit/3aa48b88c7485aca1fdfa54b3d8e53931ff067fd ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:41:02 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 05:41:02 +0000 Subject: [issue36167] DOC: Incorrect capitalization in Programming FAQ In-Reply-To: <1551529099.5.0.835675772758.issue36167@roundup.psfhosted.org> Message-ID: <1567057262.01.0.000308419033288.issue36167@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15250 pull_request: https://github.com/python/cpython/pull/15574 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:41:08 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 05:41:08 +0000 Subject: [issue36167] DOC: Incorrect capitalization in Programming FAQ In-Reply-To: <1551529099.5.0.835675772758.issue36167@roundup.psfhosted.org> Message-ID: <1567057268.8.0.505037238822.issue36167@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15251 pull_request: https://github.com/python/cpython/pull/15575 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:47:47 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 05:47:47 +0000 Subject: [issue36167] DOC: Incorrect capitalization in Programming FAQ In-Reply-To: <1551529099.5.0.835675772758.issue36167@roundup.psfhosted.org> Message-ID: <1567057667.09.0.49269858533.issue36167@roundup.psfhosted.org> miss-islington added the comment: New changeset e009a91607e7a81302b98d1b322d564ddc1fce9d by Miss Islington (bot) in branch '3.8': bpo-36167: fix an incorrect capitalization (GH-14482) https://github.com/python/cpython/commit/e009a91607e7a81302b98d1b322d564ddc1fce9d ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:49:23 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 05:49:23 +0000 Subject: [issue36167] DOC: Incorrect capitalization in Programming FAQ In-Reply-To: <1551529099.5.0.835675772758.issue36167@roundup.psfhosted.org> Message-ID: <1567057763.21.0.0219451159285.issue36167@roundup.psfhosted.org> miss-islington added the comment: New changeset 409493d0acdb8dec55868bb5c6af427ce31ff555 by Miss Islington (bot) in branch '3.7': bpo-36167: fix an incorrect capitalization (GH-14482) https://github.com/python/cpython/commit/409493d0acdb8dec55868bb5c6af427ce31ff555 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:59:46 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 05:59:46 +0000 Subject: [issue25777] Misleading descriptions in docs about invoking descriptors. In-Reply-To: <1449058941.53.0.26351823319.issue25777@psf.upfronthosting.co.za> Message-ID: <1567058386.06.0.817063314029.issue25777@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 03acba6f1a851064ba1fa78965ece4354d499c04 by Raymond Hettinger in branch 'master': bpo-25777: Wording describes a lookup, not a call (GH-15573) https://github.com/python/cpython/commit/03acba6f1a851064ba1fa78965ece4354d499c04 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 01:59:54 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 05:59:54 +0000 Subject: [issue25777] Misleading descriptions in docs about invoking descriptors. In-Reply-To: <1449058941.53.0.26351823319.issue25777@psf.upfronthosting.co.za> Message-ID: <1567058394.87.0.415828843729.issue25777@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15252 pull_request: https://github.com/python/cpython/pull/15576 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:02:16 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 06:02:16 +0000 Subject: [issue36167] DOC: Incorrect capitalization in Programming FAQ In-Reply-To: <1551529099.5.0.835675772758.issue36167@roundup.psfhosted.org> Message-ID: <1567058536.98.0.885915921668.issue36167@roundup.psfhosted.org> Ned Deily added the comment: Thank you for your contribution, Avinash! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:07:50 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 06:07:50 +0000 Subject: [issue12077] Harmonizing descriptor protocol documentation In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za> Message-ID: <1567058870.96.0.198282871021.issue12077@roundup.psfhosted.org> Raymond Hettinger added the comment: [Davide] > - use the same names for __get__ arguments throughout > the documentation (both the reference and the tutorial), > e.g. __get__(self, instance, owner) Early on the choice of variable names diverged (including in various PEPs and in the C source). I will harmonize where I can but the cat is out of the bag. > - decide whether the third argument should be optional, > or state the common usage in the reference, and fix > accordingly the examples in the howto PEP 252 specifies that it is optional. Various builtin descriptors also make it optional (function_get, staticmethod_get, classmethod_get, and property_get). I'm fixing the main docs and non-compliant code in PR 12992 > explain data, non-data and read-only descriptors in > the __set__ reference, or more simply, how the > > defintion of __set__ affects these things. That is reasonable. Will add to the datamodel docs. [Jay Parlar] > Another problem is that the examples and text in > the section "Functions and Methods" is no longer > correct in 3.x. Namely the the references to > unbound methods That was fixed a good while ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:09:05 2019 From: report at bugs.python.org (Chris Withers) Date: Thu, 29 Aug 2019 06:09:05 +0000 Subject: [issue36871] Misleading error from unittest.mock's assert_has_calls In-Reply-To: <1557451228.11.0.694440628534.issue36871@roundup.psfhosted.org> Message-ID: <1567058945.51.0.939155957053.issue36871@roundup.psfhosted.org> Chris Withers added the comment: New changeset c96127821ebda50760e788b1213975a0d5bea37f by Chris Withers (Xtreak) in branch 'master': bpo-36871: Ensure method signature is used when asserting mock calls to a method (GH13261) https://github.com/python/cpython/commit/c96127821ebda50760e788b1213975a0d5bea37f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:09:31 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 06:09:31 +0000 Subject: [issue36871] Misleading error from unittest.mock's assert_has_calls In-Reply-To: <1557451228.11.0.694440628534.issue36871@roundup.psfhosted.org> Message-ID: <1567058971.91.0.793897354844.issue36871@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15253 pull_request: https://github.com/python/cpython/pull/15577 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:09:40 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 06:09:40 +0000 Subject: [issue36871] Misleading error from unittest.mock's assert_has_calls In-Reply-To: <1557451228.11.0.694440628534.issue36871@roundup.psfhosted.org> Message-ID: <1567058980.82.0.731645133742.issue36871@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15254 pull_request: https://github.com/python/cpython/pull/15578 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:12:16 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 06:12:16 +0000 Subject: [issue25777] Misleading descriptions in docs about invoking descriptors. In-Reply-To: <1449058941.53.0.26351823319.issue25777@psf.upfronthosting.co.za> Message-ID: <1567059136.9.0.635265368578.issue25777@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset f3dca6acee609a3a12f22152fd98602c1cbadde0 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-25777: Wording describes a lookup, not a call (GH-15573) (GH-15576) https://github.com/python/cpython/commit/f3dca6acee609a3a12f22152fd98602c1cbadde0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:12:51 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 06:12:51 +0000 Subject: [issue25777] Misleading descriptions in docs about invoking descriptors. In-Reply-To: <1449058941.53.0.26351823319.issue25777@psf.upfronthosting.co.za> Message-ID: <1567059171.27.0.83844460178.issue25777@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 Aug 29 02:15:56 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 06:15:56 +0000 Subject: [issue35946] Ambiguous documentation for assert_called_with() In-Reply-To: <1549664108.48.0.268470561842.issue35946@roundup.psfhosted.org> Message-ID: <1567059356.53.0.00934130863137.issue35946@roundup.psfhosted.org> Ned Deily added the comment: New changeset f5896a05edf5df91fb1b55bd481ba5b2a3682f4e by Ned Deily (R?mi Lapeyre) in branch 'master': bpo-35946: Improve assert_called_with documentation (GH-11796) https://github.com/python/cpython/commit/f5896a05edf5df91fb1b55bd481ba5b2a3682f4e ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:16:25 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 06:16:25 +0000 Subject: [issue35946] Ambiguous documentation for assert_called_with() In-Reply-To: <1549664108.48.0.268470561842.issue35946@roundup.psfhosted.org> Message-ID: <1567059385.08.0.593239326624.issue35946@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15255 pull_request: https://github.com/python/cpython/pull/15579 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:22:12 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 06:22:12 +0000 Subject: [issue12077] Harmonizing descriptor protocol documentation In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za> Message-ID: <1567059732.75.0.633648352957.issue12077@roundup.psfhosted.org> Raymond Hettinger added the comment: See PR 12992 for the cross-reference from the __set__ docs to the section covering data and non-data descriptors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:25:27 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 06:25:27 +0000 Subject: [issue37960] repr() of buffered and text streams silences too many exceptions In-Reply-To: <1566892180.39.0.647932070898.issue37960@roundup.psfhosted.org> Message-ID: <1567059927.69.0.74085680684.issue37960@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset b235a1b47394eedc5f8ea4cf214f56c4c6932e59 by Serhiy Storchaka in branch 'master': bpo-37960: Silence only necessary errors in repr() of buffered and text streams. (GH-15543) https://github.com/python/cpython/commit/b235a1b47394eedc5f8ea4cf214f56c4c6932e59 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:25:34 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 06:25:34 +0000 Subject: [issue37960] repr() of buffered and text streams silences too many exceptions In-Reply-To: <1566892180.39.0.647932070898.issue37960@roundup.psfhosted.org> Message-ID: <1567059934.14.0.1568568142.issue37960@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15256 pull_request: https://github.com/python/cpython/pull/15580 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:29:44 2019 From: report at bugs.python.org (Yehuda Katz) Date: Thu, 29 Aug 2019 06:29:44 +0000 Subject: [issue37968] Add a turtle module function to draw a circle centered at the turtle In-Reply-To: <1567038969.22.0.471992453823.issue37968@roundup.psfhosted.org> Message-ID: Yehuda Katz added the comment: Thanks for the clarifications. Yehuda(Israel) On Thu, Aug 29, 2019 at 3:36 AM Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > Yehuda, thank you for the suggestions, but we're going to decline. > > ---------- > resolution: -> rejected > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:30:06 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 06:30:06 +0000 Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default language set to English In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za> Message-ID: <1567060206.6.0.0667999712309.issue18378@roundup.psfhosted.org> Ned Deily added the comment: Ronald's PR 14738 LGTM. I merged it to master and backported for 3.8.0b4 and 3.7.5. Thanks, everyone! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:30:26 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 06:30:26 +0000 Subject: [issue37950] ast.dump() with incomplete node In-Reply-To: <1566804954.58.0.654310469231.issue37950@roundup.psfhosted.org> Message-ID: <1567060226.15.0.138618937001.issue37950@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset e64f948e762a6b9fd02e2902ccf42438df6fcb61 by Serhiy Storchaka in branch 'master': bpo-37950: Fix ast.dump() when call with incompletely initialized node. (GH-15510) https://github.com/python/cpython/commit/e64f948e762a6b9fd02e2902ccf42438df6fcb61 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:30:39 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 06:30:39 +0000 Subject: [issue37950] ast.dump() with incomplete node In-Reply-To: <1566804954.58.0.654310469231.issue37950@roundup.psfhosted.org> Message-ID: <1567060239.54.0.142004966873.issue37950@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15257 pull_request: https://github.com/python/cpython/pull/15581 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:30:48 2019 From: report at bugs.python.org (Yehuda Katz) Date: Thu, 29 Aug 2019 06:30:48 +0000 Subject: [issue37968] Add a turtle module function to draw a circle centered at the turtle In-Reply-To: <1567038969.22.0.471992453823.issue37968@roundup.psfhosted.org> Message-ID: Yehuda Katz added the comment: Thanks for the clarifications. Yehuda(Israel) On Thu, Aug 29, 2019 at 3:36 AM Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > Yehuda, thank you for the suggestions, but we're going to decline. > > ---------- > resolution: -> rejected > stage: -> resolved > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:37:16 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 06:37:16 +0000 Subject: [issue37950] ast.dump() with incomplete node In-Reply-To: <1566804954.58.0.654310469231.issue37950@roundup.psfhosted.org> Message-ID: <1567060636.78.0.156193816537.issue37950@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +15258 pull_request: https://github.com/python/cpython/pull/15582 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:39:50 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 06:39:50 +0000 Subject: [issue35946] Ambiguous documentation for assert_called_with() In-Reply-To: <1549664108.48.0.268470561842.issue35946@roundup.psfhosted.org> Message-ID: <1567060790.67.0.00811815078628.issue35946@roundup.psfhosted.org> miss-islington added the comment: New changeset 612d3935ec0b2fbe88b3fae8167f0c503c61a9ca by Miss Islington (bot) in branch '3.8': bpo-35946: Improve assert_called_with documentation (GH-11796) https://github.com/python/cpython/commit/612d3935ec0b2fbe88b3fae8167f0c503c61a9ca ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:46:53 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 06:46:53 +0000 Subject: [issue25435] Wrong function calls and referring to not removed concepts in descriptor HowTo (documentation) In-Reply-To: <1445194189.09.0.0973348556564.issue25435@psf.upfronthosting.co.za> Message-ID: <1567061213.37.0.296145058186.issue25435@roundup.psfhosted.org> Raymond Hettinger added the comment: This was fixed a long time ago. ---------- resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:56:13 2019 From: report at bugs.python.org (B Siemerink) Date: Thu, 29 Aug 2019 06:56:13 +0000 Subject: [issue37482] Email address display name fails with both encoded words and special chars In-Reply-To: <1562068275.57.0.247896906946.issue37482@roundup.psfhosted.org> Message-ID: <1567061773.24.0.578444143389.issue37482@roundup.psfhosted.org> B Siemerink added the comment: Thank you all! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:57:41 2019 From: report at bugs.python.org (Chris Withers) Date: Thu, 29 Aug 2019 06:57:41 +0000 Subject: [issue36871] Misleading error from unittest.mock's assert_has_calls In-Reply-To: <1557451228.11.0.694440628534.issue36871@roundup.psfhosted.org> Message-ID: <1567061861.76.0.555871092062.issue36871@roundup.psfhosted.org> Chris Withers added the comment: New changeset be310e03d0b84ef56e9d35b0b1b21d685b7ea371 by Chris Withers (Miss Islington (bot)) in branch '3.7': bpo-36871: Ensure method signature is used when asserting mock calls to a method (GH15577) https://github.com/python/cpython/commit/be310e03d0b84ef56e9d35b0b1b21d685b7ea371 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 02:58:29 2019 From: report at bugs.python.org (Chris Withers) Date: Thu, 29 Aug 2019 06:58:29 +0000 Subject: [issue36871] Misleading error from unittest.mock's assert_has_calls In-Reply-To: <1557451228.11.0.694440628534.issue36871@roundup.psfhosted.org> Message-ID: <1567061909.82.0.343447687632.issue36871@roundup.psfhosted.org> Chris Withers added the comment: New changeset 38d311d79e57479f7a684c2cd298293033dc4990 by Chris Withers (Miss Islington (bot)) in branch '3.8': bpo-36871: Ensure method signature is used when asserting mock calls to a method (GH15578) https://github.com/python/cpython/commit/38d311d79e57479f7a684c2cd298293033dc4990 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:03:28 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 29 Aug 2019 07:03:28 +0000 Subject: [issue36871] Misleading error from unittest.mock's assert_has_calls In-Reply-To: <1557451228.11.0.694440628534.issue36871@roundup.psfhosted.org> Message-ID: <1567062208.49.0.766796080738.issue36871@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Closing this as fixed since all PRs are merged. Thank you all :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:04:47 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 07:04:47 +0000 Subject: [issue37950] ast.dump() with incomplete node In-Reply-To: <1566804954.58.0.654310469231.issue37950@roundup.psfhosted.org> Message-ID: <1567062287.66.0.626792024059.issue37950@roundup.psfhosted.org> miss-islington added the comment: New changeset d3d2650cf84e6be0f84d6d0d538999d1e0cfdd43 by Miss Islington (bot) in branch '3.7': bpo-37950: Fix ast.dump() when call with incompletely initialized node. (GH-15510) https://github.com/python/cpython/commit/d3d2650cf84e6be0f84d6d0d538999d1e0cfdd43 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:06:34 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 29 Aug 2019 07:06:34 +0000 Subject: [issue37974] zip() docstring should say 'iterator' instead of 'object with __next__()' In-Reply-To: <1567049445.71.0.232910822835.issue37974@roundup.psfhosted.org> Message-ID: <1567062394.79.0.0480048277785.issue37974@roundup.psfhosted.org> Change by Karthikeyan Singaravelan : ---------- nosy: +rhettinger type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:10:10 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 07:10:10 +0000 Subject: [issue37974] zip() docstring should say 'iterator' instead of 'object with __next__()' In-Reply-To: <1567049445.71.0.232910822835.issue37974@roundup.psfhosted.org> Message-ID: <1567062610.59.0.119430483652.issue37974@roundup.psfhosted.org> Raymond Hettinger added the comment: This looks fine to me. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:30:23 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 07:30:23 +0000 Subject: [issue35946] Ambiguous documentation for assert_called_with() In-Reply-To: <1549664108.48.0.268470561842.issue35946@roundup.psfhosted.org> Message-ID: <1567063823.48.0.339206214699.issue35946@roundup.psfhosted.org> Ned Deily added the comment: Thanks for the report and thanks for the PR! Merged for 3.8.0b4. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.9 -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:31:42 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 07:31:42 +0000 Subject: [issue36871] Misleading error from unittest.mock's assert_has_calls In-Reply-To: <1557451228.11.0.694440628534.issue36871@roundup.psfhosted.org> Message-ID: <1567063902.68.0.760886703525.issue36871@roundup.psfhosted.org> Change by Ned Deily : ---------- versions: +Python 3.9 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:36:20 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 07:36:20 +0000 Subject: [issue37372] datetime.time unpickling fails in case of python2 pickle with seconds>=24 In-Reply-To: <1561220113.72.0.97808916119.issue37372@roundup.psfhosted.org> Message-ID: <1567064180.84.0.155697076094.issue37372@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 122376df550b71dd3bec0513c7483cc1714212fa by Serhiy Storchaka (Justin Blanchard) in branch 'master': bpo-37372: Fix error unpickling datetime.time objects from Python 2 with seconds>=24. (GH-14307) https://github.com/python/cpython/commit/122376df550b71dd3bec0513c7483cc1714212fa ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:36:54 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 07:36:54 +0000 Subject: [issue37372] datetime.time unpickling fails in case of python2 pickle with seconds>=24 In-Reply-To: <1561220113.72.0.97808916119.issue37372@roundup.psfhosted.org> Message-ID: <1567064214.41.0.639626947526.issue37372@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15259 pull_request: https://github.com/python/cpython/pull/15583 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:37:03 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 07:37:03 +0000 Subject: [issue37372] datetime.time unpickling fails in case of python2 pickle with seconds>=24 In-Reply-To: <1561220113.72.0.97808916119.issue37372@roundup.psfhosted.org> Message-ID: <1567064223.24.0.568218567074.issue37372@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15260 pull_request: https://github.com/python/cpython/pull/15584 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:44:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 07:44:06 +0000 Subject: [issue23674] super() documentation isn't very clear In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za> Message-ID: <1567064646.69.0.0317294252318.issue23674@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset cd81f0500fe98c7f4cddb06530fffabd14f036b8 by Raymond Hettinger in branch 'master': bpo-23674: Clarify ambiguities in super() docs (#15564) https://github.com/python/cpython/commit/cd81f0500fe98c7f4cddb06530fffabd14f036b8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:44:13 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 07:44:13 +0000 Subject: [issue23674] super() documentation isn't very clear In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za> Message-ID: <1567064653.14.0.820137483479.issue23674@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15261 pull_request: https://github.com/python/cpython/pull/15585 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:50:37 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 07:50:37 +0000 Subject: [issue37950] ast.dump() with incomplete node In-Reply-To: <1566804954.58.0.654310469231.issue37950@roundup.psfhosted.org> Message-ID: <1567065037.78.0.976179837448.issue37950@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 097eae5b9b4801d34bb900c01b5e6a80f028bc12 by Serhiy Storchaka in branch '3.8': [3.8] bpo-37950: Fix ast.dump() when call with incompletely initialized node. (GH-15510) (GH-15582) https://github.com/python/cpython/commit/097eae5b9b4801d34bb900c01b5e6a80f028bc12 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:54:45 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 07:54:45 +0000 Subject: [issue23674] super() documentation isn't very clear In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za> Message-ID: <1567065285.05.0.918758751196.issue23674@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15262 pull_request: https://github.com/python/cpython/pull/15586 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:56:09 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 07:56:09 +0000 Subject: [issue37372] datetime.time unpickling fails in case of python2 pickle with seconds>=24 In-Reply-To: <1561220113.72.0.97808916119.issue37372@roundup.psfhosted.org> Message-ID: <1567065369.46.0.577335847205.issue37372@roundup.psfhosted.org> miss-islington added the comment: New changeset d1d42bf4a404f092fe90fe8984481c507a64ef0a by Miss Islington (bot) in branch '3.8': bpo-37372: Fix error unpickling datetime.time objects from Python 2 with seconds>=24. (GH-14307) https://github.com/python/cpython/commit/d1d42bf4a404f092fe90fe8984481c507a64ef0a ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:56:22 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 07:56:22 +0000 Subject: [issue23674] super() documentation isn't very clear In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za> Message-ID: <1567065382.88.0.604808310526.issue23674@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 Aug 29 03:56:54 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 07:56:54 +0000 Subject: [issue37176] super() docs don't say what super() does In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org> Message-ID: <1567065414.16.0.986102963322.issue37176@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:57:44 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 07:57:44 +0000 Subject: [issue37372] datetime.time unpickling fails in case of python2 pickle with seconds>=24 In-Reply-To: <1561220113.72.0.97808916119.issue37372@roundup.psfhosted.org> Message-ID: <1567065464.09.0.705123242574.issue37372@roundup.psfhosted.org> miss-islington added the comment: New changeset 6b50c10f675a9e8438024c5fcc592b0d38d8c62d by Miss Islington (bot) in branch '3.7': bpo-37372: Fix error unpickling datetime.time objects from Python 2 with seconds>=24. (GH-14307) https://github.com/python/cpython/commit/6b50c10f675a9e8438024c5fcc592b0d38d8c62d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:58:11 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 07:58:11 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1567065491.17.0.0978116270866.issue16468@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 84125fed2a45a9e454d7e870d8bbaf6ece3d41e8 by Raymond Hettinger in branch 'master': bpo-16468: Clarify which objects can be passed to "choices" in argparse (GH-15566) https://github.com/python/cpython/commit/84125fed2a45a9e454d7e870d8bbaf6ece3d41e8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:58:22 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 07:58:22 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1567065502.98.0.410200930342.issue16468@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15263 pull_request: https://github.com/python/cpython/pull/15587 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 03:59:11 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 07:59:11 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1567065551.93.0.269189216346.issue16468@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:03:04 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 08:03:04 +0000 Subject: [issue23674] super() documentation isn't very clear In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za> Message-ID: <1567065784.82.0.633473971745.issue23674@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 43b7ed77a8224c378b436ad3385733454198be41 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-23674: Clarify ambiguities in super() docs (GH-15564) (GH-15586) https://github.com/python/cpython/commit/43b7ed77a8224c378b436ad3385733454198be41 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:11:26 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 08:11:26 +0000 Subject: [issue34410] itertools.tee not thread-safe; can segfault interpreter when wrapped iterator releases GIL In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za> Message-ID: <1567066286.41.0.664995834589.issue34410@roundup.psfhosted.org> Serhiy Storchaka added the comment: The documentation changes should be backported. And I think we need a change like PR 9254, but with raising a RuntimeError instead of adding the value to the queue, to be applied in older versions. It may be better to apply it even to the developed version. There is nothing wrong with creating the tee iterator in one thread and using it the other thread. Or using the tee iterators with external locking. I afraid that PR 15567 can break a legitimate code. ---------- stage: resolved -> needs patch status: closed -> open versions: +Python 2.7, Python 3.7, Python 3.8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:12:38 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 08:12:38 +0000 Subject: [issue37372] datetime.time unpickling fails in case of python2 pickle with seconds>=24 In-Reply-To: <1561220113.72.0.97808916119.issue37372@roundup.psfhosted.org> Message-ID: <1567066358.01.0.943476001135.issue37372@roundup.psfhosted.org> Serhiy Storchaka added the comment: Thank you for your contribution Justin! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:12:59 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 08:12:59 +0000 Subject: [issue37950] ast.dump() with incomplete node In-Reply-To: <1566804954.58.0.654310469231.issue37950@roundup.psfhosted.org> Message-ID: <1567066379.8.0.940034543578.issue37950@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 Aug 29 04:13:34 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 08:13:34 +0000 Subject: [issue37960] repr() of buffered and text streams silences too many exceptions In-Reply-To: <1566892180.39.0.647932070898.issue37960@roundup.psfhosted.org> Message-ID: <1567066414.86.0.112434830088.issue37960@roundup.psfhosted.org> miss-islington added the comment: New changeset 102130a63c93fde7bcabbbf4fae1ebce38888981 by Miss Islington (bot) in branch '3.8': bpo-37960: Silence only necessary errors in repr() of buffered and text streams. (GH-15543) https://github.com/python/cpython/commit/102130a63c93fde7bcabbbf4fae1ebce38888981 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:14:01 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 08:14:01 +0000 Subject: [issue37960] repr() of buffered and text streams silences too many exceptions In-Reply-To: <1566892180.39.0.647932070898.issue37960@roundup.psfhosted.org> Message-ID: <1567066441.46.0.483678232574.issue37960@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:15:24 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 08:15:24 +0000 Subject: [issue16468] argparse only supports iterable choices In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za> Message-ID: <1567066524.14.0.827466819855.issue16468@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 0d45d50e421b46b56195821580c3760b43813106 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-16468: Clarify which objects can be passed to "choices" in argparse (GH-15566) (GH-15587) https://github.com/python/cpython/commit/0d45d50e421b46b56195821580c3760b43813106 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:23:29 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 08:23:29 +0000 Subject: [issue10978] Add optional argument to Semaphore.release for releasing multiple threads In-Reply-To: <1295655336.58.0.55708711889.issue10978@psf.upfronthosting.co.za> Message-ID: <1567067009.25.0.681304580981.issue10978@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +15264 pull_request: https://github.com/python/cpython/pull/15588 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:25:52 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 08:25:52 +0000 Subject: [issue34410] itertools.tee not thread-safe; can segfault interpreter when wrapped iterator releases GIL In-Reply-To: <1534298908.58.0.56676864532.issue34410@psf.upfronthosting.co.za> Message-ID: <1567067152.1.0.885265083982.issue34410@roundup.psfhosted.org> Raymond Hettinger added the comment: Go ahead and take this in any direction you want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:27:45 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 08:27:45 +0000 Subject: [issue36743] Docs: Descript __get__ signature defined differently across the docs In-Reply-To: <1556387803.45.0.177981206888.issue36743@roundup.psfhosted.org> Message-ID: <1567067265.18.0.655984856965.issue36743@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 0dac68f1e593c11612ed54af9edb865d398f3b05 by Raymond Hettinger in branch 'master': bpo-36743: __get__ is sometimes called without the owner argument (#12992) https://github.com/python/cpython/commit/0dac68f1e593c11612ed54af9edb865d398f3b05 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:27:54 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 08:27:54 +0000 Subject: [issue36743] Docs: Descript __get__ signature defined differently across the docs In-Reply-To: <1556387803.45.0.177981206888.issue36743@roundup.psfhosted.org> Message-ID: <1567067274.06.0.157519843946.issue36743@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15265 pull_request: https://github.com/python/cpython/pull/15589 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:28:45 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 08:28:45 +0000 Subject: [issue36743] Docs: Descript __get__ signature defined differently across the docs In-Reply-To: <1556387803.45.0.177981206888.issue36743@roundup.psfhosted.org> Message-ID: <1567067325.24.0.111882849511.issue36743@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 Aug 29 04:29:06 2019 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 29 Aug 2019 08:29:06 +0000 Subject: [issue37973] improve docstrings of sys.float_info In-Reply-To: <1567048617.81.0.748558704563.issue37973@roundup.psfhosted.org> Message-ID: <1567067346.52.0.989579952371.issue37973@roundup.psfhosted.org> Mark Dickinson added the comment: Unhelpful indeed. +1 to updating those docstrings to match the details at docs.python.org. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:29:30 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 08:29:30 +0000 Subject: [issue12077] Harmonizing descriptor protocol documentation In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za> Message-ID: <1567067370.9.0.443787122552.issue12077@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:32:21 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 08:32:21 +0000 Subject: [issue10978] Add optional argument to Semaphore.release for releasing multiple threads In-Reply-To: <1295655336.58.0.55708711889.issue10978@psf.upfronthosting.co.za> Message-ID: <1567067541.83.0.816561051468.issue10978@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- versions: +Python 3.9 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:45:29 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 08:45:29 +0000 Subject: [issue10978] Add optional argument to Semaphore.release for releasing multiple threads In-Reply-To: <1295655336.58.0.55708711889.issue10978@psf.upfronthosting.co.za> Message-ID: <1567068329.13.0.457502258892.issue10978@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 35f6301d68bdb0517be284421782d64407dfe72c by Raymond Hettinger in branch 'master': bpo-10978: Semaphores can release multiple threads at a time (GH-15588) https://github.com/python/cpython/commit/35f6301d68bdb0517be284421782d64407dfe72c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 04:45:42 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 08:45:42 +0000 Subject: [issue10978] Add optional argument to Semaphore.release for releasing multiple threads In-Reply-To: <1295655336.58.0.55708711889.issue10978@psf.upfronthosting.co.za> Message-ID: <1567068342.91.0.949072715399.issue10978@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 Aug 29 05:01:20 2019 From: report at bugs.python.org (Aleksey) Date: Thu, 29 Aug 2019 09:01:20 +0000 Subject: =?utf-8?q?=5Bissue37975=5D_Typo_in_the_documentation_by_C-API_DateTime_Ob?= =?utf-8?q?jects=C2=B6?= Message-ID: <1567069280.84.0.885119110407.issue37975@roundup.psfhosted.org> New submission from Aleksey : In the documentation by Python 3.5 C-API DateTime Objects (https://docs.python.org/3.5/c-api/datetime.html) method PyDateTime_DELTA_GET_MICROSECOND has not "S" in the end of method name. But in the header file "datetime.h", this method has "S" and so named PyDateTime_DELTA_GET_MICROSECONDS. ---------- assignee: docs at python components: Documentation messages: 350758 nosy: Nukopol, docs at python priority: normal severity: normal status: open title: Typo in the documentation by C-API DateTime Objects? type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 05:02:36 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 09:02:36 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1567069356.19.0.754770642905.issue8425@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- pull_requests: +15266 pull_request: https://github.com/python/cpython/pull/15590 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 05:02:55 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 09:02:55 +0000 Subject: [issue36743] Docs: Descript __get__ signature defined differently across the docs In-Reply-To: <1556387803.45.0.177981206888.issue36743@roundup.psfhosted.org> Message-ID: <1567069375.43.0.0633568838986.issue36743@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset c71ae1a45bd6e6d0f5aebc470b35f5a7dc0d8078 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8': bpo-36743: __get__ is sometimes called without the owner argument (GH-12992) (GH-15589) https://github.com/python/cpython/commit/c71ae1a45bd6e6d0f5aebc470b35f5a7dc0d8078 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 05:16:18 2019 From: report at bugs.python.org (Karthikeyan Singaravelan) Date: Thu, 29 Aug 2019 09:16:18 +0000 Subject: =?utf-8?q?=5Bissue37975=5D_Typo_in_the_documentation_by_C-API_DateTime_Ob?= =?utf-8?q?jects=C2=B6?= In-Reply-To: <1567069280.84.0.885119110407.issue37975@roundup.psfhosted.org> Message-ID: <1567070178.78.0.81492190638.issue37975@roundup.psfhosted.org> Karthikeyan Singaravelan added the comment: Thanks for the report. This was fixed in 82cd3cede804ca694fb0657fd985d5eff84a414f (https://bugs.python.org/issue31678). It was not merged to 3.5 at that time. Now 3.5 only accepts security fixes so I would propose closing this as duplicate of issue31678. ---------- nosy: +xtreak _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 05:39:06 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 09:39:06 +0000 Subject: [issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used. In-Reply-To: <1437906052.21.0.35165181866.issue24726@psf.upfronthosting.co.za> Message-ID: <1567071546.69.0.411231774789.issue24726@roundup.psfhosted.org> Change by Raymond Hettinger : ---------- resolution: -> wont fix stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 05:53:21 2019 From: report at bugs.python.org (Inada Naoki) Date: Thu, 29 Aug 2019 09:53:21 +0000 Subject: [issue37587] JSON loads performance improvement for long strings In-Reply-To: <1563028922.54.0.821649437171.issue37587@roundup.psfhosted.org> Message-ID: <1567072401.47.0.035521403374.issue37587@roundup.psfhosted.org> Change by Inada Naoki : ---------- pull_requests: +15267 pull_request: https://github.com/python/cpython/pull/15591 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 05:55:38 2019 From: report at bugs.python.org (Inada Naoki) Date: Thu, 29 Aug 2019 09:55:38 +0000 Subject: [issue37587] JSON loads performance improvement for long strings In-Reply-To: <1563028922.54.0.821649437171.issue37587@roundup.psfhosted.org> Message-ID: <1567072538.01.0.664308749923.issue37587@roundup.psfhosted.org> Inada Naoki added the comment: @mpaolini I don't have enough time in these weeks. Would you try PR-15591? I confirmed up to 4x speedup. But I'm afraid about there is performance regression in simple cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 06:19:18 2019 From: report at bugs.python.org (Joran van Apeldoorn) Date: Thu, 29 Aug 2019 10:19:18 +0000 Subject: [issue37971] Wrong trace with multiple decorators (linenumber wrong in frame) In-Reply-To: <1567017172.25.0.486267767179.issue37971@roundup.psfhosted.org> Message-ID: <1567073958.75.0.110624243546.issue37971@roundup.psfhosted.org> Joran van Apeldoorn added the comment: Digging around with the disassembler shows that this originates in the bytecode. Code: -------- import dis src = """ def printingdec(f): raise Exception() return f def dummydec(f): return f @printingdec @dummydec def foo(): pass """ code = compile(src,filename="bug.py",mode='exec') print(dis.dis(code)) --------- gives on 3.6: 2 0 LOAD_CONST 0 () 2 LOAD_CONST 1 ('printingdec') 4 MAKE_FUNCTION 0 6 STORE_NAME 0 (printingdec) 6 8 LOAD_CONST 2 () 10 LOAD_CONST 3 ('dummydec') 12 MAKE_FUNCTION 0 14 STORE_NAME 1 (dummydec) 9 16 LOAD_NAME 0 (printingdec) 10 18 LOAD_NAME 1 (dummydec) 20 LOAD_CONST 4 () 22 LOAD_CONST 5 ('foo') 24 MAKE_FUNCTION 0 26 CALL_FUNCTION 1 28 CALL_FUNCTION 1 30 STORE_NAME 2 (foo) 32 LOAD_CONST 6 (None) 34 RETURN_VALUE None and on 3.9: 2 0 LOAD_CONST 0 () 2 LOAD_CONST 1 ('printingdec') 4 MAKE_FUNCTION 0 6 STORE_NAME 0 (printingdec) 6 8 LOAD_CONST 2 () 10 LOAD_CONST 3 ('dummydec') 12 MAKE_FUNCTION 0 14 STORE_NAME 1 (dummydec) 9 16 LOAD_NAME 0 (printingdec) 10 18 LOAD_NAME 1 (dummydec) 11 20 LOAD_CONST 4 () 22 LOAD_CONST 5 ('foo') 24 MAKE_FUNCTION 0 26 CALL_FUNCTION 1 28 CALL_FUNCTION 1 30 STORE_NAME 2 (foo) 32 LOAD_CONST 6 (None) 34 RETURN_VALUE Disassembly of : 3 0 LOAD_GLOBAL 0 (Exception) 2 CALL_FUNCTION 0 4 RAISE_VARARGS 1 4 6 LOAD_FAST 0 (f) 8 RETURN_VALUE Disassembly of : 7 0 LOAD_FAST 0 (f) 2 RETURN_VALUE Disassembly of : 12 0 LOAD_CONST 0 (None) 2 RETURN_VALUE None The change from 3.6 seems to be that a new line number is introduced for instruction 20, loading the function code, which seems reasonable. It would feel natural if the line number of the decorator would be used for instructions 26 & 28, the decorator call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 06:30:10 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 29 Aug 2019 10:30:10 +0000 Subject: [issue37976] zip() shadows TypeError raised in __iter__() of source iterable Message-ID: <1567074610.14.0.32757366853.issue37976@roundup.psfhosted.org> New submission from Sergey Fedoseev : zip() shadows TypeError raised in __iter__() of source iterable: In [21]: class Iterable: ...: def __init__(self, n): ...: self.n = n ...: def __iter__(self): ...: return iter(range(self.n)) ...: In [22]: zip(Iterable('one')) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () ----> 1 zip(Iterable('one')) TypeError: zip argument #1 must support iteration ---------- messages: 350763 nosy: sir-sigurd priority: normal severity: normal status: open title: zip() shadows TypeError raised in __iter__() of source iterable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 06:31:11 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 29 Aug 2019 10:31:11 +0000 Subject: [issue37976] zip() shadows TypeError raised in __iter__() of source iterable In-Reply-To: <1567074610.14.0.32757366853.issue37976@roundup.psfhosted.org> Message-ID: <1567074671.38.0.104604902678.issue37976@roundup.psfhosted.org> Change by Sergey Fedoseev : ---------- keywords: +patch pull_requests: +15268 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15592 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 06:43:23 2019 From: report at bugs.python.org (Vlad Shcherbina) Date: Thu, 29 Aug 2019 10:43:23 +0000 Subject: [issue35889] sqlite3.Row doesn't have useful repr In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org> Message-ID: <1567075403.9.0.162898511618.issue35889@roundup.psfhosted.org> Vlad Shcherbina added the comment: 1. "This patch adds too many lines of code and not enough value." If the maintainers judge it so, I have nothing to say. You have the responsibility to keep the codebase relatively simple. 2a. "Existing programs made with the assumption that repr(row) is short (albeit useless) will break when it becomes not so short." I have no experience maintaining popular language implementations, so I defer to your judgement on what level of backward compatibility is warranted. 2b. "New users of new repr(row) will run into problems because its size is unbounded." I think this objection is invalid, as I explained in the comment: https://bugs.python.org/issue35889#msg336291 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 07:57:37 2019 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 29 Aug 2019 11:57:37 +0000 Subject: [issue37954] Multiple tests are leaking references in AMD64 Windows8.1 Refleaks 3.x and x86 Gentoo Refleaks 3.x buildbots In-Reply-To: <1566829813.13.0.292904797891.issue37954@roundup.psfhosted.org> Message-ID: <1567079857.98.0.420215409295.issue37954@roundup.psfhosted.org> Nick Coghlan added the comment: Thank you Pablo! Even having seen your fix, it still took me a couple of rescans of the original PR to figure out exactly how I'd broken it in the first place (refactoring to call an existing function without noticing that the replaced code included an extra DECREF). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 08:20:16 2019 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 29 Aug 2019 12:20:16 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level In-Reply-To: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> Message-ID: <1567081216.45.0.908399225503.issue37947@roundup.psfhosted.org> Change by Nick Coghlan : ---------- pull_requests: +15269 pull_request: https://github.com/python/cpython/pull/15593 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 08:22:43 2019 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 29 Aug 2019 12:22:43 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level In-Reply-To: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> Message-ID: <1567081363.27.0.964919099007.issue37947@roundup.psfhosted.org> Nick Coghlan added the comment: Reviewing the PR post-merge, I'm pretty sure this has introduced a double-decrement bug due to the original code being hard to read (the error cases did the decrement inside the helper function, while the success case did it in the calling function). https://github.com/python/cpython/pull/15593 builds on your PR by removing the recursion counter adjustments from inside the helper function, leaving only the ones in the calling function. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 08:31:35 2019 From: report at bugs.python.org (Pablo Galindo Salgado) Date: Thu, 29 Aug 2019 12:31:35 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level In-Reply-To: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> Message-ID: <1567081895.57.0.890960203956.issue37947@roundup.psfhosted.org> Pablo Galindo Salgado added the comment: Thank you very much Nick for correcting this! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 08:37:01 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 12:37:01 +0000 Subject: [issue37976] zip() shadows TypeError raised in __iter__() of source iterable In-Reply-To: <1567074610.14.0.32757366853.issue37976@roundup.psfhosted.org> Message-ID: <1567082221.87.0.998186536094.issue37976@roundup.psfhosted.org> Serhiy Storchaka added the comment: I am not even sure this is a bug. ---------- nosy: +rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 08:43:12 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 12:43:12 +0000 Subject: [issue37971] Wrong trace with multiple decorators (linenumber wrong in frame) In-Reply-To: <1567017172.25.0.486267767179.issue37971@roundup.psfhosted.org> Message-ID: <1567082592.98.0.321610736056.issue37971@roundup.psfhosted.org> Serhiy Storchaka added the comment: It makes sense. If write decorators as explicit function calls: decorated = ( deco1( deco2( original ) ) ) The line number of decorator itself will be used for CALL_FUNCTION: 2 0 LOAD_NAME 0 (deco1) 3 2 LOAD_NAME 1 (deco2) 4 4 LOAD_NAME 2 (original) 3 6 CALL_FUNCTION 1 2 8 CALL_FUNCTION 1 1 10 STORE_NAME 3 (decorated) 12 LOAD_CONST 0 (None) 14 RETURN_VALUE But I suppose this will add more headache for coverage.py. ---------- nosy: +nedbat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 08:43:33 2019 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 29 Aug 2019 12:43:33 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level In-Reply-To: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> Message-ID: <1567082613.3.0.10446320054.issue37947@roundup.psfhosted.org> Nick Coghlan added the comment: Reviewing all the code that touches recursion_depth (both in the symtable and in the thread state), I'm not seeing any sanity checks that ensure our increments and decrements *balance*. So I'm going to add one to PySymTable_BuildObject. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 08:54:49 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Aug 2019 12:54:49 +0000 Subject: [issue36833] Add tests for Datetime C API Macros In-Reply-To: <1557238651.7.0.774867491617.issue36833@roundup.psfhosted.org> Message-ID: <1567083289.63.0.504783177328.issue36833@roundup.psfhosted.org> STINNER Victor added the comment: New changeset 2c5fb1711818926862d0d7b2e5effcaa5a5eb002 by Victor Stinner (Joannah Nanjekye) in branch 'master': bpo-36833: Add tests for Datetime C API Macros (GH-14842) https://github.com/python/cpython/commit/2c5fb1711818926862d0d7b2e5effcaa5a5eb002 ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 08:55:19 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Aug 2019 12:55:19 +0000 Subject: [issue36833] Add tests for Datetime C API Macros In-Reply-To: <1557238651.7.0.774867491617.issue36833@roundup.psfhosted.org> Message-ID: <1567083319.54.0.377904561208.issue36833@roundup.psfhosted.org> STINNER Victor added the comment: Thanks Joannah Nanjekye, well done ;-) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 09:09:30 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Aug 2019 13:09:30 +0000 Subject: [issue37878] Sub-Interpreters : Document PyThreadState_DeleteCurrent() In-Reply-To: <1565985235.6.0.212314052144.issue37878@roundup.psfhosted.org> Message-ID: <1567084170.47.0.563134829544.issue37878@roundup.psfhosted.org> STINNER Victor added the comment: I did a GitHub code search on "PyThreadState_DeleteCurrent" in C code: https://github.com/search?l=C&q=PyThreadState_DeleteCurrent&type=Code I looked at the first 6 pages: I only found copies of the Python source code, but no *call* to this function. It seems like this function is not used outside Python, so it's fine to remove it. Anyway, if an user complains lately, we can add it back. It's fine. In case of doubt, in this case, I'm fine with removing the function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 09:12:43 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 29 Aug 2019 13:12:43 +0000 Subject: [issue37976] zip() shadows TypeError raised in __iter__() of source iterable In-Reply-To: <1567074610.14.0.32757366853.issue37976@roundup.psfhosted.org> Message-ID: <1567084363.69.0.00246532323528.issue37976@roundup.psfhosted.org> Sergey Fedoseev added the comment: Maybe it's not clear from description, but traceback only show the line with zip(), so it doesn't help at localizing the source of exception at all. You only see that 'argument #N must support iteration', but that argument has __iter__() i.e. it supports iteration. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 09:19:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Aug 2019 13:19:15 +0000 Subject: [issue37966] is_normalized is much slower at "no" than the standard's algorithm In-Reply-To: <1566964376.46.0.968905414274.issue37966@roundup.psfhosted.org> Message-ID: <1567084755.26.0.408620089476.issue37966@roundup.psfhosted.org> Change by STINNER Victor : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 09:25:26 2019 From: report at bugs.python.org (Sergey Fedoseev) Date: Thu, 29 Aug 2019 13:25:26 +0000 Subject: [issue37976] zip() shadows TypeError raised in __iter__() of source iterable In-Reply-To: <1567074610.14.0.32757366853.issue37976@roundup.psfhosted.org> Message-ID: <1567085126.48.0.928333650187.issue37976@roundup.psfhosted.org> Sergey Fedoseev added the comment: Also using this example class: In [5]: iter(Iterable('one')) --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () ----> 1 iter(Iterable('one')) in __iter__(self) 3 self.n = n 4 def __iter__(self): ----> 5 return iter(range(self.n)) 6 TypeError: range() integer end argument expected, got str. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 09:27:01 2019 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 29 Aug 2019 13:27:01 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level In-Reply-To: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> Message-ID: <1567085221.49.0.503171273328.issue37947@roundup.psfhosted.org> Nick Coghlan added the comment: New changeset 06145230c833c3db5dab8858e11bcd550a37c57f by Nick Coghlan in branch 'master': bpo-37947: Avoid double-decrement in symtable recursion counting (GH-15593) https://github.com/python/cpython/commit/06145230c833c3db5dab8858e11bcd550a37c57f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 09:27:16 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 13:27:16 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level In-Reply-To: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> Message-ID: <1567085236.93.0.414004097518.issue37947@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15270 pull_request: https://github.com/python/cpython/pull/15594 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 09:28:33 2019 From: report at bugs.python.org (Daniel Pope) Date: Thu, 29 Aug 2019 13:28:33 +0000 Subject: [issue37977] Big red pickle security warning should stress the point even more Message-ID: <1567085313.43.0.156950423126.issue37977@roundup.psfhosted.org> New submission from Daniel Pope : CVEs related to unpickling untrusted data continue to come up a few times a year: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pickle This is certainly the tip of the iceberg. In a previous role I noted several internal services that could be compromised with maliciously crafted pickles. In my current role I can already see two internal services that look vulnerable. And in both organisations, little attention was paid to pickle data exchanged with other users over network filesystems, which may allow privilege escalation. Chatting to Alex Willmer after his Europython talk in 2018 (https://github.com/moreati/pickle-fuzz/blob/master/Rehabilitating%20Pickle.pdf) we discussed that the red warning in the docs is still not prominent enough, even after moving it to the top of the page in https://bugs.python.org/issue9105. The warning currently says: "Warning: The pickle module is not secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source." I would suggest several improvements: * Simpler, more direct English. * Explain the severity of vulnerability that doing this will cause. * Link to the hmac module which can be used to prevent tampering. * Link to the json module which is safer if less powerful. * Simply making the red box bigger (adding more text) will increase the prominence of the warning. ---------- assignee: docs at python components: Documentation messages: 350777 nosy: docs at python, lordmauve priority: normal severity: normal status: open title: Big red pickle security warning should stress the point even more type: security versions: Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 09:32:53 2019 From: report at bugs.python.org (Daniel Pope) Date: Thu, 29 Aug 2019 13:32:53 +0000 Subject: [issue37977] Big red pickle security warning should stress the point even more In-Reply-To: <1567085313.43.0.156950423126.issue37977@roundup.psfhosted.org> Message-ID: <1567085573.33.0.322709244852.issue37977@roundup.psfhosted.org> Change by Daniel Pope : ---------- keywords: +patch pull_requests: +15271 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15595 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 09:35:49 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Aug 2019 13:35:49 +0000 Subject: [issue32847] Add DirectoryNotEmptyError subclass of OSError In-Reply-To: <1518664317.8.0.467229070634.issue32847@psf.upfronthosting.co.za> Message-ID: <1567085749.64.0.937624095648.issue32847@roundup.psfhosted.org> STINNER Victor added the comment: > Maybe we should add one? I don't think that we need to add an *builtin* exception for every single possible errno. On Linux with Python 3.7, I count 133 different error numbers: >>> len([name for name in dir(errno) if name.startswith("E")]) 133 PEP 3151 explains the rationale for added OSError subclasses. I think that we should focus on the most common ones, especially the ones which are available on all platforms. I have no opinion about "errno 39 (Directory not empty)". Is it a "common" error? ---------- nosy: +vstinner _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 09:46:25 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 13:46:25 +0000 Subject: [issue37947] symtable_handle_namedexpr does not adjust correctly the recursion level In-Reply-To: <1566788950.92.0.897432675692.issue37947@roundup.psfhosted.org> Message-ID: <1567086385.26.0.973235331328.issue37947@roundup.psfhosted.org> miss-islington added the comment: New changeset 384c6d72d9a12764282ccc2d3935232a34a7cfbe by Miss Islington (bot) in branch '3.8': bpo-37947: Avoid double-decrement in symtable recursion counting (GH-15593) https://github.com/python/cpython/commit/384c6d72d9a12764282ccc2d3935232a34a7cfbe ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 09:48:49 2019 From: report at bugs.python.org (JemyTan) Date: Thu, 29 Aug 2019 13:48:49 +0000 Subject: [issue37978] Importing an unused package causes the function of another package to malfunction Message-ID: <1567086529.72.0.126651693669.issue37978@roundup.psfhosted.org> New submission from JemyTan : After commenting out the first line of code, the result of the program is different. I stepped in to debug(the program runs to line 30), and found that when it hit the code"from numpy.dual import inv as func" It seems to use different inv(). ------------------------------------ Environment: python: 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05) [MSC v.1916 64 bit (AMD64)] sklearn: 0.21.3 numpy: 1.17.0 ---------- components: Windows files: np.py messages: 350780 nosy: JemyTan, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Importing an unused package causes the function of another package to malfunction type: crash versions: Python 3.7 Added file: https://bugs.python.org/file48566/np.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 09:54:34 2019 From: report at bugs.python.org (Christian Heimes) Date: Thu, 29 Aug 2019 13:54:34 +0000 Subject: [issue37978] Importing an unused package causes the function of another package to malfunction In-Reply-To: <1567086529.72.0.126651693669.issue37978@roundup.psfhosted.org> Message-ID: <1567086874.04.0.978826918436.issue37978@roundup.psfhosted.org> Christian Heimes added the comment: Please report the bug with sklearn and numpy. I assume that the import of sklearn has a side-effect on numpy. ---------- nosy: +christian.heimes resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 10:36:27 2019 From: report at bugs.python.org (Joran van Apeldoorn) Date: Thu, 29 Aug 2019 14:36:27 +0000 Subject: [issue37971] Wrong trace with multiple decorators (linenumber wrong in frame) In-Reply-To: <1567017172.25.0.486267767179.issue37971@roundup.psfhosted.org> Message-ID: <1567089387.98.0.379395277596.issue37971@roundup.psfhosted.org> Joran van Apeldoorn added the comment: After compiling 3.7 and 3.8 as well it seems that the change happened between those versions. I was a able to patch compiler.c for 3.9 to make it work (first time changing cpython internals, so no guarantees). Patch is attached. This trips up one of the tests in test_trace however, since both the LOAD_NAME before the function def and the CALL_FUNCTION after are counted as a visit to the decorator line. However, this is also the case for your example with the decorators written out, running: def deco1(f): return f def deco2(f): return f def go(): f = 5 f = ( deco1( deco2( f ) ) ) import trace tracer = trace.Trace(count=1,trace=0,countfuncs=0, countcallers=0) tracer.run('go()') for k,v in tracer.results().counts.items(): print(k,v) gives ('', 1) 1 ('/home/user/projects/ShortUse/tracebug/cpython3.9clean/mytracetest.py', 8) 1 ('/home/user/projects/ShortUse/tracebug/cpython3.9clean/mytracetest.py', 10) 2 ('/home/user/projects/ShortUse/tracebug/cpython3.9clean/mytracetest.py', 11) 2 ('/home/user/projects/ShortUse/tracebug/cpython3.9clean/mytracetest.py', 12) 1 ('/home/user/projects/ShortUse/tracebug/cpython3.9clean/mytracetest.py', 5) 1 ('/home/user/projects/ShortUse/tracebug/cpython3.9clean/mytracetest.py', 2) 1 ('/home/user/projects/ShortUse/tracebug/cpython3.9clean/mytracetest.py', 9) 1 while clearly each function is only called ones. In addition, to get back to the 3.6/3.7 problem as well, on 3.6 the slight modification def deco1(f): raise Exception() return f def deco2(f): return f f = 5 f = ( deco1( deco2( f ) ) ) gives Traceback (most recent call last): File "sixtest.py", line 12, in f File "sixtest.py", line 2, in deco1 raise Exception() Exception So the problem is not only with decorators, it is with function calls on multiple lines, in all versions. It seems that: 1. The problem with tracebacks for function calls on multiple lines has been fixed in going from 3.7 to 3.8 (should this fix be merged down as well?) 2. The same problem for decorators has not been fixed (patch attached for 3.9) 3. The fix in 3.8 introduced a bug in the trace module which seems hard to fix. ---------- keywords: +patch Added file: https://bugs.python.org/file48567/decolinenumbers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 10:37:05 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 29 Aug 2019 14:37:05 +0000 Subject: [issue32847] Add DirectoryNotEmptyError subclass of OSError In-Reply-To: <1518664317.8.0.467229070634.issue32847@psf.upfronthosting.co.za> Message-ID: <1567089425.69.0.693906181029.issue32847@roundup.psfhosted.org> Eryk Sun added the comment: > I have no opinion about "errno 39 (Directory not empty)". > Is it a "common" error? Python's code base never specifically handles ENOTEMPTY. On the other hand, in terms of basic operations on files and directories, I think implementing DirectoryNotEmptyError follows naturally from the existing set: FileNotFoundError, FileExistsError, NotADirectoryError, and IsADirectoryError. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 10:39:34 2019 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 29 Aug 2019 14:39:34 +0000 Subject: [issue37979] Document an alternative to ISO 8601 parsing Message-ID: <1567089574.63.0.345364917917.issue37979@roundup.psfhosted.org> New submission from Paul Ganssle : Per Antoine's comment in the discourse thread ( https://discuss.python.org/t/parse-z-timezone-suffix-in-datetime/2220/6 ): > ... the doc isn?t helpful, as it doesn?t give any alternative. I think we can link to dateutil.parser.isoparse as an alternative. I'm happy to field other options for ISO 8601 parsers instead, though considering that fromisoformat is adapted from dateutil.parser.isoparse, it seems reasonable to link them. ---------- assignee: p-ganssle components: Documentation messages: 350784 nosy: p-ganssle priority: low severity: normal stage: needs patch status: open title: Document an alternative to ISO 8601 parsing type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 10:41:21 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 29 Aug 2019 14:41:21 +0000 Subject: [issue32847] Add DirectoryNotEmptyError subclass of OSError In-Reply-To: <1518664317.8.0.467229070634.issue32847@psf.upfronthosting.co.za> Message-ID: <1567089681.94.0.144374615508.issue32847@roundup.psfhosted.org> Antoine Pitrou added the comment: According to POSIX, the only system calls that can fail with ENOTEMPTY are rmdir(), rename() and unlinkat(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 10:41:58 2019 From: report at bugs.python.org (Paul Ganssle) Date: Thu, 29 Aug 2019 14:41:58 +0000 Subject: [issue37979] Document an alternative to ISO 8601 parsing In-Reply-To: <1567089574.63.0.345364917917.issue37979@roundup.psfhosted.org> Message-ID: <1567089718.32.0.767037088773.issue37979@roundup.psfhosted.org> Change by Paul Ganssle : ---------- keywords: +patch pull_requests: +15272 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15596 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 10:47:55 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 14:47:55 +0000 Subject: [issue37979] Document an alternative to ISO 8601 parsing In-Reply-To: <1567089574.63.0.345364917917.issue37979@roundup.psfhosted.org> Message-ID: <1567090075.91.0.157528279886.issue37979@roundup.psfhosted.org> miss-islington added the comment: New changeset 59725f3badb3028636c8906ecac4ceb0a37f3982 by Miss Islington (bot) (Paul Ganssle) in branch 'master': bpo-37979: Add alternative to fromisoformat in documentation (GH-15596) https://github.com/python/cpython/commit/59725f3badb3028636c8906ecac4ceb0a37f3982 ---------- nosy: +miss-islington _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 10:48:04 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 14:48:04 +0000 Subject: [issue37979] Document an alternative to ISO 8601 parsing In-Reply-To: <1567089574.63.0.345364917917.issue37979@roundup.psfhosted.org> Message-ID: <1567090084.34.0.582401818642.issue37979@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15273 pull_request: https://github.com/python/cpython/pull/15597 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 10:48:11 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 14:48:11 +0000 Subject: [issue37979] Document an alternative to ISO 8601 parsing In-Reply-To: <1567089574.63.0.345364917917.issue37979@roundup.psfhosted.org> Message-ID: <1567090091.93.0.351745791945.issue37979@roundup.psfhosted.org> Change by miss-islington : ---------- pull_requests: +15274 pull_request: https://github.com/python/cpython/pull/15598 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 10:49:12 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 14:49:12 +0000 Subject: [issue37034] Argument Clinic omits name of keyword-only parameter on _PyArg_BadArgument() call In-Reply-To: <1558693785.23.0.512986851321.issue37034@roundup.psfhosted.org> Message-ID: <1567090152.01.0.342560291425.issue37034@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 4901fe274bc82b95dc89bcb3de8802a3dfedab32 by Serhiy Storchaka (R?mi Lapeyre) in branch 'master': bpo-37034: Display argument name on errors with keyword arguments with Argument Clinic. (GH-13593) https://github.com/python/cpython/commit/4901fe274bc82b95dc89bcb3de8802a3dfedab32 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 10:54:07 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 14:54:07 +0000 Subject: [issue37979] Document an alternative to ISO 8601 parsing In-Reply-To: <1567089574.63.0.345364917917.issue37979@roundup.psfhosted.org> Message-ID: <1567090447.81.0.750704819413.issue37979@roundup.psfhosted.org> miss-islington added the comment: New changeset 8ba8cc51a9899594f7fe66fe790973d83fd3d657 by Miss Islington (bot) in branch '3.7': bpo-37979: Add alternative to fromisoformat in documentation (GH-15596) https://github.com/python/cpython/commit/8ba8cc51a9899594f7fe66fe790973d83fd3d657 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 10:54:40 2019 From: report at bugs.python.org (miss-islington) Date: Thu, 29 Aug 2019 14:54:40 +0000 Subject: [issue37979] Document an alternative to ISO 8601 parsing In-Reply-To: <1567089574.63.0.345364917917.issue37979@roundup.psfhosted.org> Message-ID: <1567090480.55.0.840153358795.issue37979@roundup.psfhosted.org> miss-islington added the comment: New changeset 9db66a2b5ab6a302bc46421712f13b0afd94654b by Miss Islington (bot) in branch '3.8': bpo-37979: Add alternative to fromisoformat in documentation (GH-15596) https://github.com/python/cpython/commit/9db66a2b5ab6a302bc46421712f13b0afd94654b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 10:55:44 2019 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 29 Aug 2019 14:55:44 +0000 Subject: [issue37979] Document an alternative to ISO 8601 parsing In-Reply-To: <1567089574.63.0.345364917917.issue37979@roundup.psfhosted.org> Message-ID: <1567090544.94.0.993222523007.issue37979@roundup.psfhosted.org> Antoine Pitrou added the comment: Thanks for contributing this, Paul! ---------- nosy: +pitrou resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 11:09:52 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 15:09:52 +0000 Subject: [issue37034] Argument Clinic omits name of keyword-only parameter on _PyArg_BadArgument() call In-Reply-To: <1558693785.23.0.512986851321.issue37034@roundup.psfhosted.org> Message-ID: <1567091392.81.0.355471848465.issue37034@roundup.psfhosted.org> Change by Serhiy Storchaka : ---------- pull_requests: +15275 pull_request: https://github.com/python/cpython/pull/15599 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 11:30:02 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 15:30:02 +0000 Subject: [issue37034] Argument Clinic omits name of keyword-only parameter on _PyArg_BadArgument() call In-Reply-To: <1558693785.23.0.512986851321.issue37034@roundup.psfhosted.org> Message-ID: <1567092602.85.0.0882739169802.issue37034@roundup.psfhosted.org> Serhiy Storchaka added the comment: New changeset 96631dcb11c2786f470d4586bf23ecca14361506 by Serhiy Storchaka in branch '3.8': [3.8] bpo-37034: Display argument name on errors with keyword arguments with Argument Clinic. (GH-13593). (GH-15599) https://github.com/python/cpython/commit/96631dcb11c2786f470d4586bf23ecca14361506 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 11:43:56 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 15:43:56 +0000 Subject: [issue37971] Wrong trace with multiple decorators (linenumber wrong in frame) In-Reply-To: <1567017172.25.0.486267767179.issue37971@roundup.psfhosted.org> Message-ID: <1567093436.52.0.310512549978.issue37971@roundup.psfhosted.org> Serhiy Storchaka added the comment: Thank you for your patch Joran. We now use GitHub, do you mind to create a pull request? You need to use 4-spaces indentation instead of tabs. Would be nice if you have signed the PSF contributor agreement https://www.python.org/psf/contrib/contrib-form/ . ---------- components: +Interpreter Core versions: +Python 3.8, Python 3.9 -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 11:52:22 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 15:52:22 +0000 Subject: [issue37034] Argument Clinic omits name of keyword-only parameter on _PyArg_BadArgument() call In-Reply-To: <1558693785.23.0.512986851321.issue37034@roundup.psfhosted.org> Message-ID: <1567093942.15.0.909631605753.issue37034@roundup.psfhosted.org> Serhiy Storchaka added the comment: Thank you R?mi! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:01:49 2019 From: report at bugs.python.org (Dong-hee Na) Date: Thu, 29 Aug 2019 16:01:49 +0000 Subject: [issue37798] Add C fastpath for statistics.NormalDist.inv_cdf() In-Reply-To: <1565325806.95.0.315734354533.issue37798@roundup.psfhosted.org> Message-ID: <1567094509.76.0.619887340532.issue37798@roundup.psfhosted.org> Dong-hee Na added the comment: @rhettinger If you are okay, Can you review PR 15546, please? IMHO, this issue should be fixed ASAP... Thanks again ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:03:04 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 16:03:04 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1567094584.92.0.455515102133.issue8425@roundup.psfhosted.org> Raymond Hettinger added the comment: New changeset 88ea166dadb8aeb34541a0a464662dea222629e5 by Raymond Hettinger in branch 'master': bpo-8425: Fast path for set inplace difference when the second set is large (GH-15590) https://github.com/python/cpython/commit/88ea166dadb8aeb34541a0a464662dea222629e5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:03:37 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 16:03:37 +0000 Subject: [issue8425] a -= b should be fast if a is a small set and b is a large set In-Reply-To: <1271438382.18.0.76932438586.issue8425@psf.upfronthosting.co.za> Message-ID: <1567094617.39.0.788051861436.issue8425@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 Aug 29 12:30:07 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Aug 2019 16:30:07 +0000 Subject: [issue37933] faulthandler causes segfaults In-Reply-To: <1566595381.91.0.0185169812386.issue37933@roundup.psfhosted.org> Message-ID: <1567096207.62.0.964509166261.issue37933@roundup.psfhosted.org> STINNER Victor added the comment: New changeset e278335a6eb049e6028db9a8dcb8baac6cb365ee by Victor Stinner (Thomas A Caswell) in branch 'master': bpo-37933: Fix faulthandler.cancel_dump_traceback_later() (GH-15440) https://github.com/python/cpython/commit/e278335a6eb049e6028db9a8dcb8baac6cb365ee ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:30:51 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Aug 2019 16:30:51 +0000 Subject: [issue37933] faulthandler causes segfaults In-Reply-To: <1566595381.91.0.0185169812386.issue37933@roundup.psfhosted.org> Message-ID: <1567096250.99.0.902011155577.issue37933@roundup.psfhosted.org> STINNER Victor added the comment: Thanks Thomas. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:31:00 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Thu, 29 Aug 2019 16:31:00 +0000 Subject: [issue37970] urllib.parse docstrings incomplete In-Reply-To: <1567009599.74.0.471882594509.issue37970@roundup.psfhosted.org> Message-ID: <1567096260.25.0.223547906432.issue37970@roundup.psfhosted.org> Joannah Nanjekye added the comment: > Also, the note about not splitting netloc is misleading; the components > of netloc (username, password, hostname, and port) are available as >extra attributes of the returned SplitResult. Also, the docs in urllib.parse.rst should also be updated to correct this misleading statement. ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:37:07 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Thu, 29 Aug 2019 16:37:07 +0000 Subject: [issue32847] Add DirectoryNotEmptyError subclass of OSError In-Reply-To: <1518664317.8.0.467229070634.issue32847@psf.upfronthosting.co.za> Message-ID: <1567096627.01.0.501204501137.issue32847@roundup.psfhosted.org> Change by Joannah Nanjekye : ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:37:39 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Aug 2019 16:37:39 +0000 Subject: [issue37034] Argument Clinic omits name of keyword-only parameter on _PyArg_BadArgument() call In-Reply-To: <1558693785.23.0.512986851321.issue37034@roundup.psfhosted.org> Message-ID: <1567096659.25.0.440935680754.issue37034@roundup.psfhosted.org> STINNER Victor added the comment: Thanks, that's a great enhancement! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:38:15 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Aug 2019 16:38:15 +0000 Subject: [issue34651] Disallow fork in a subinterpreter. In-Reply-To: <1536786263.28.0.956365154283.issue34651@psf.upfronthosting.co.za> Message-ID: <1567096695.53.0.0148230546324.issue34651@roundup.psfhosted.org> Change by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:39:02 2019 From: report at bugs.python.org (Thomas Caswell) Date: Thu, 29 Aug 2019 16:39:02 +0000 Subject: [issue37980] regression when passing numpy bools to sorted(..., reverse=r) Message-ID: <1567096742.32.0.970581980709.issue37980@roundup.psfhosted.org> New submission from Thomas Caswell : In python37, numpy1.17 the following runs without warning. import numpy as np sorted([1, 2], reverse=np.bool_(True)) with python38 this emits a DeprecationWarning: In future, it will be an error for 'np.bool_' scalars to be interpreted as an index I bisected this back to https://github.com/python/cpython/pull/11952 which looks very intentional, however it is tripping deprecation warnings in numpy to prevent things like `[1, 2, 3][np.bool_(False), np.bool_(True)]` from doing surprising things. I have previously gotten the sense that core would like to know about these sorts of regressions rather than just handling them down-stream. I will be opening an issue with numpy as well. ---------- files: numpy_warning_bisect.log messages: 350800 nosy: tcaswell priority: normal severity: normal status: open title: regression when passing numpy bools to sorted(..., reverse=r) versions: Python 3.8 Added file: https://bugs.python.org/file48568/numpy_warning_bisect.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:40:21 2019 From: report at bugs.python.org (Thomas Caswell) Date: Thu, 29 Aug 2019 16:40:21 +0000 Subject: [issue37980] regression when passing numpy bools to sorted(..., reverse=r) In-Reply-To: <1567096742.32.0.970581980709.issue37980@roundup.psfhosted.org> Message-ID: <1567096821.44.0.829842925196.issue37980@roundup.psfhosted.org> Change by Thomas Caswell : Added file: https://bugs.python.org/file48569/python_bisect.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:41:06 2019 From: report at bugs.python.org (Thomas Caswell) Date: Thu, 29 Aug 2019 16:41:06 +0000 Subject: [issue37980] regression when passing numpy bools to sorted(..., reverse=r) In-Reply-To: <1567096742.32.0.970581980709.issue37980@roundup.psfhosted.org> Message-ID: <1567096866.62.0.504685305346.issue37980@roundup.psfhosted.org> Change by Thomas Caswell : Added file: https://bugs.python.org/file48570/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:41:25 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Thu, 29 Aug 2019 16:41:25 +0000 Subject: [issue37973] improve docstrings of sys.float_info In-Reply-To: <1567048617.81.0.748558704563.issue37973@roundup.psfhosted.org> Message-ID: <1567096885.54.0.481534448661.issue37973@roundup.psfhosted.org> Joannah Nanjekye added the comment: See also #37970 ---------- nosy: +nanjekyejoannah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:48:04 2019 From: report at bugs.python.org (=?utf-8?q?Alexander_Podg=C3=B3rski?=) Date: Thu, 29 Aug 2019 16:48:04 +0000 Subject: [issue37981] Can't install Python 3.7.4 x64 on Win 8.1 Message-ID: <1567097284.11.0.163984980296.issue37981@roundup.psfhosted.org> New submission from Alexander Podg?rski : Have double "No Python 3.7 installation detected" error ---------- components: Installation files: python_installation_log.txt messages: 350802 nosy: Alexander Podg?rski priority: normal severity: normal status: open title: Can't install Python 3.7.4 x64 on Win 8.1 versions: Python 3.7 Added file: https://bugs.python.org/file48571/python_installation_log.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:48:11 2019 From: report at bugs.python.org (Thomas Caswell) Date: Thu, 29 Aug 2019 16:48:11 +0000 Subject: [issue37980] regression when passing numpy bools to sorted(..., reverse=r) In-Reply-To: <1567096742.32.0.970581980709.issue37980@roundup.psfhosted.org> Message-ID: <1567097291.39.0.762945843819.issue37980@roundup.psfhosted.org> Thomas Caswell added the comment: xref numpy issue https://github.com/numpy/numpy/issues/14397 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:52:21 2019 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 29 Aug 2019 16:52:21 +0000 Subject: [issue37973] improve docstrings of sys.float_info In-Reply-To: <1567048617.81.0.748558704563.issue37973@roundup.psfhosted.org> Message-ID: <1567097541.87.0.763864564929.issue37973@roundup.psfhosted.org> Mark Dickinson added the comment: @nanjekyejoannah I'm not seeing how that issue is related to this one (except that they're both about docstrings). Can you elaborate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 12:58:46 2019 From: report at bugs.python.org (Joannah Nanjekye) Date: Thu, 29 Aug 2019 16:58:46 +0000 Subject: [issue37973] improve docstrings of sys.float_info In-Reply-To: <1567048617.81.0.748558704563.issue37973@roundup.psfhosted.org> Message-ID: <1567097926.06.0.978434173958.issue37973@roundup.psfhosted.org> Joannah Nanjekye added the comment: I just referenced another area that may need help updating/improving doc strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 13:03:17 2019 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 29 Aug 2019 17:03:17 +0000 Subject: [issue37980] regression when passing numpy bools to sorted(..., reverse=r) In-Reply-To: <1567096742.32.0.970581980709.issue37980@roundup.psfhosted.org> Message-ID: <1567098197.73.0.190486062444.issue37980@roundup.psfhosted.org> Mark Dickinson added the comment: Closely related: #37427. I'm not sure why that issue was closed. My naive expectation would be that in most cases where an API specifies a flag, an arbitrary Python object can be used for that flag (and is then interpreted in boolean context). That's the natural behaviour that you get when handling flags in pure Python code. Ex: https://github.com/python/cpython/blob/8ba8cc51a9899594f7fe66fe790973d83fd3d657/Lib/pathlib.py#L190 ---------- nosy: +mark.dickinson, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 13:04:17 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 17:04:17 +0000 Subject: [issue37976] zip() shadows TypeError raised in __iter__() of source iterable In-Reply-To: <1567074610.14.0.32757366853.issue37976@roundup.psfhosted.org> Message-ID: <1567098257.3.0.957057063911.issue37976@roundup.psfhosted.org> Raymond Hettinger added the comment: > I am not even sure this is a bug. It really isn't :-) But it is okay to want to improve the traceback. Using _PyErr_FormatFromCause() is plausible, but the resulting traceback is messy. Since there isn't much value in reporting which iterable number has failed, I prefer to just simplify the code with: - if (PyErr_ExceptionMatches(PyExc_TypeError)) - PyErr_Format(PyExc_TypeError, - "zip argument #%zd must support iteration", - i+1); The same change can also be applied to itertools.zip_longest(). ---------- assignee: -> rhettinger components: +Library (Lib) priority: normal -> low versions: +Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 13:04:27 2019 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 29 Aug 2019 17:04:27 +0000 Subject: [issue37427] sorted, list.sort reject non-boolean objects with __bool__() as `reverse` parameter In-Reply-To: <1561629105.71.0.460566565999.issue37427@roundup.psfhosted.org> Message-ID: <1567098267.08.0.592362112317.issue37427@roundup.psfhosted.org> Mark Dickinson added the comment: See also #37980. I'd support a change to have the `reversed` argument to `sort` and `sorted` be automatically interpreted in boolean context. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 13:41:45 2019 From: report at bugs.python.org (STINNER Victor) Date: Thu, 29 Aug 2019 17:41:45 +0000 Subject: [issue37961] Tracemalloc traces do not include original stack trace length In-Reply-To: <1566894205.32.0.427554502238.issue37961@roundup.psfhosted.org> Message-ID: <1567100505.24.0.0612014756042.issue37961@roundup.psfhosted.org> STINNER Victor added the comment: > However, if the number of frames is truncated, there's no way to know the original length of the stack traces. PR 15545 makes each trace 4 bytes (sizeof int) larger. Would it be enough for you to only know if the traceback is truncated? tracemalloc is already "memory heavy", so I don't think that making trace_t larger is a blocker issue :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 13:49:17 2019 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 29 Aug 2019 17:49:17 +0000 Subject: [issue37976] zip() shadows TypeError raised in __iter__() of source iterable In-Reply-To: <1567074610.14.0.32757366853.issue37976@roundup.psfhosted.org> Message-ID: <1567100957.62.0.111143432205.issue37976@roundup.psfhosted.org> Serhiy Storchaka added the comment: Agree. This is an improvement of UX. The initial code was added in 8572b4fedf7e6ee4cd350680d53cd0a21574b083. Other option is to check ahead if the argument is an iterable. if (!item->ob_type->tp_iter && !PySequence_Check(item)) { // Raise specific TypeError } (We can introduce a special API for this, PyIterable_Check, if there are other use cases). This is a part of larger issue. When we parse arguments using Argument Clinic, in some cases we can check the type ahead and report what argument (by name or positional number) of what function has wrong type. But in other cases we just call the converting function, and the detailed information about argument and function is lost. For example: >>> ''.encode(123) Traceback (most recent call last): File "", line 1, in TypeError: encode() argument 'encoding' must be str, not int >>> ''.encode('\0') Traceback (most recent call last): File "", line 1, in ValueError: embedded null character ---------- nosy: +tim.peters type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 13:49:45 2019 From: report at bugs.python.org (hai shi) Date: Thu, 29 Aug 2019 17:49:45 +0000 Subject: [issue15125] argparse: positional arguments containing - in name not handled well In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za> Message-ID: <1567100985.6.0.156418127469.issue15125@roundup.psfhosted.org> hai shi added the comment: How about: 1. Adding documentation as steven said. 2. If user use '-' of positional arguments in latest cpython, we cloud remind user that `the '-' of positional arguments be replaced by '_' since cpython 4.0` 3.Applying Simon Law's patch. ---------- nosy: +shihai1991 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 14:33:21 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 18:33:21 +0000 Subject: [issue37976] zip() shadows TypeError raised in __iter__() of source iterable In-Reply-To: <1567074610.14.0.32757366853.issue37976@roundup.psfhosted.org> Message-ID: <1567103601.28.0.714374734668.issue37976@roundup.psfhosted.org> Raymond Hettinger added the comment: > Other option is to check ahead if the argument is an iterable. The other tools that consume iterators don't go down this path and it doesn't seem to have been a problem in practice. So, I recommend that we not invent new problems that we didn't already have ;-) Leaving for Sergey to update his PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 14:40:06 2019 From: report at bugs.python.org (tsufeki) Date: Thu, 29 Aug 2019 18:40:06 +0000 Subject: [issue30988] Exception parsing invalid email address headers starting or ending with dot In-Reply-To: <1500699002.76.0.343337119039.issue30988@psf.upfronthosting.co.za> Message-ID: <1567104006.83.0.834457727444.issue30988@roundup.psfhosted.org> Change by tsufeki : ---------- keywords: +patch pull_requests: +15276 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15600 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 14:48:26 2019 From: report at bugs.python.org (Julien Danjou) Date: Thu, 29 Aug 2019 18:48:26 +0000 Subject: [issue37961] Tracemalloc traces do not include original stack trace length In-Reply-To: <1566894205.32.0.427554502238.issue37961@roundup.psfhosted.org> Message-ID: <1567104506.36.0.786677654634.issue37961@roundup.psfhosted.org> Julien Danjou added the comment: That's a good question. Considering that Py_DEFAULT_RECURSION_LIMIT is 1000, we could probably settle on 2 bytes by using an uint16_t which ought to be enough unless people regularly trace Python stack traces bigger that are bigger than 2^16. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 14:59:56 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 29 Aug 2019 18:59:56 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1567105196.44.0.902570264161.issue37834@roundup.psfhosted.org> ?ukasz Langa added the comment: There's a bug on macOS that is blocking the release regarding `stat.FILE_ATTRIBUTE_REPARSE_POINT` being used to check whether `os.stat_result` objects have the `st_file_attributes` attribute. ---------- nosy: +lukasz.langa resolution: fixed -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 15:05:55 2019 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 29 Aug 2019 19:05:55 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1567105555.56.0.573921917472.issue37834@roundup.psfhosted.org> ?ukasz Langa added the comment: Unit tests didn't catch it since it fails on older macOS releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 15:17:07 2019 From: report at bugs.python.org (Brad Solomon) Date: Thu, 29 Aug 2019 19:17:07 +0000 Subject: [issue37982] Add a --minify argument to json.tool Message-ID: <1567106227.18.0.64278078149.issue37982@roundup.psfhosted.org> New submission from Brad Solomon : I propose adding a command line `--minify` flag to the json/tool.py module. This flag, if specified, uses `indent=None` and `separators=(',', ':')` to eliminate indent and separator whitespace in the output. Minifying JSON (as is also done frequently with JS, CSS, and sometimes HTML) is common practice, and would be useful to have as a command-line tool rather than a user needing to use an online resource to do so. ---------- components: IO messages: 350817 nosy: bsolomon1124 priority: normal severity: normal status: open title: Add a --minify argument to json.tool type: enhancement versions: Python 3.9 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 15:35:03 2019 From: report at bugs.python.org (Brad Solomon) Date: Thu, 29 Aug 2019 19:35:03 +0000 Subject: [issue37982] Add a --minify argument to json.tool In-Reply-To: <1567106227.18.0.64278078149.issue37982@roundup.psfhosted.org> Message-ID: <1567107303.26.0.965328399521.issue37982@roundup.psfhosted.org> Change by Brad Solomon : ---------- keywords: +patch pull_requests: +15277 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15601 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 15:42:36 2019 From: report at bugs.python.org (Ned Deily) Date: Thu, 29 Aug 2019 19:42:36 +0000 Subject: [issue37834] readlink on Windows cannot read app exec links In-Reply-To: <1565635762.02.0.826831872137.issue37834@roundup.psfhosted.org> Message-ID: <1567107756.12.0.753565328771.issue37834@roundup.psfhosted.org> Ned Deily added the comment: One problem seems to be that the code added for this issue assumes that the documentation is correct in implying that the stat.FILE_ATTRIBUTE_* constants (like stat.FILE_ATTRIBUTE_REPARSE_POINT) are only present on Windows. But besides being conditionally created in _stat.c, they are also undconditionally defined in stat.py on all platforms. That makes some of the tests in shutil.py, like: if hasattr(stat, 'FILE_ATTRIBUTE_REPARSE_POINT'): to determine which versions of _rmtree_islink and _rmtree_isdir to define problematic. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 15:43:20 2019 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 29 Aug 2019 19:43:20 +0000 Subject: [issue37982] Add a --minify argument to json.tool In-Reply-To: <1567106227.18.0.64278078149.issue37982@roundup.psfhosted.org> Message-ID: <1567107800.04.0.762715810593.issue37982@roundup.psfhosted.org> Raymond Hettinger added the comment: -0 ISTM that minifying isn't something one usually does with a command-line tool. Instead, it is part of the program generating JSON in the first place. IOW, minification is useful in the standard library but not a part of json.tool which normally used a a pretty printer (perhaps to *undo* someone else's minification). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Aug 29 15:47:44 2019 From: report at bugs.python.org (Eryk Sun) Date: Thu, 29 Aug 2019 19:47:44 +0000 Subject: [issue37945] test_locale failing In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org> Message-ID: <1567108064.16.0.803534269254.issue37945@roundup.psfhosted.org> Eryk Sun added the comment: Here's some additional background information for work on this issue. A Unix locale identifier has the following form: "language[_territory][.codeset][@modifier]" | "POSIX" | "C" | "" | NULL (X/Open Portability Guide, Issue 4, 1992 -- aka XPG4) Some systems also implement "C.UTF-8". The language and territory should use ISO 639 and ISO 3166 alpha-2 codes. The "@" modifier may indicate an alternate script such as "sr_RS at latin" or an alternate currency such as "de_DE at euro". For the optional codeset, IANA publishes the following table of character sets: http://www.iana.org/assignments/character-sets/character-sets.xhtml In Debian Linux, the available encodings are defined by mapping files in "/usr/share/i18n/charmaps". But encodings can't be arbitrarily used in locales at run time. A locale has to be generated (see "/etc/locale.gen") before it's available. A Windows (not ucrt) locale name has the following form: "ISO639Language[-ISO15924Script][-ISO3166Region][SubTag][_SortOrder]" | "" | LOCALE_NAME_INVARIANT | "!x-sys-default-locale" | LOCALE_NAME_SYSTEM_DEFAULT | NULL | LOCALE_NAME_USER_DEFAULT The invariant locale provides stable data. The system and user default locales vary according to the Control Panel "Region" settings. A locale name is based on BCP 47 language tags, with the form "-