[issue46834] test_gdb started to fail on buildbot/s390x RHEL7
Nikita Sobolev added the comment: Sorry, wrong link. It started to fail after this commit: https://github.com/python/cpython/commit/66b3cd7063322a9f5c922a97bbd06fdb9830 -- ___ Python tracker <https://bugs.python.org/issue46834> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46834] test_gdb started to fail on buildbot/s390x RHEL7
New submission from Nikita Sobolev : Log sample: ``` == FAIL: test_up_then_down (test.test_gdb.StackNavigationTests) -- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/test/test_gdb.py", line 782, in test_up_then_down self.assertMultilineMatches(bt, ^^^ File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/test/test_gdb.py", line 297, in assertMultilineMatches self.fail(msg='%r did not match %r' % (actual, pattern)) AssertionError: 'Breakpoint 1 at 0x801ff160: file Python/bltinmodule.c, line 1168.\n[Thread debugging using libthread_db enabled]\nUsing host libthread_db library "/lib64/libthread_db.so.1".\n\nBreakpoint 1, builtin_id (self=, v=<_PyRuntime+2184>) at Python/bltinmodule.c:1168\n1168\t{\n#16 Frame 0x3fffdfb1118, for file , line 9, in bar (a=1, b=2, c=3)\n#16 Frame 0x3fffdfb1090, for file , line 6, in foo (a=1, b=2, c=3)\n#16 Frame 0x3fffdfb1020, for file , line 14, in ()\nUnable to find an older python frame\n#4 Frame 0x3fffdfb11a8, for file , line 12, in baz (args=(1, 2, 3))\n' did not match '^.*\n#[0-9]+ Frame 0x-?[0-9a-f]+, for file , line 12, in baz \\(args=\\(1, 2, 3\\)\\)\n#[0-9]+ \n#[0-9]+ Frame 0x-?[0-9a-f]+, for file , line 12, in baz \\(args=\\(1, 2, 3\\)\\)\n$' -- Ran 32 tests in 15.312s FAILED (failures=53) test test_gdb failed 1 test failed again: test_gdb ``` Full log (too long): https://buildbot.python.org/all/#/builders/179/builds/1769/steps/5/logs/stdio It started to happen (at least more often - however, I cannot find any older failures at the moment) after this commit: https://github.com/python/cpython/commit/b899126094731bc49fecb61f2c1b7557d74ca839 Build link: https://buildbot.python.org/all/#/builders/402/builds/1744 Latest commits (at this moment): - Fails: https://github.com/python/cpython/commit/375a56bd4015596c0cf44129c8842a1fe7199785 - Passes: https://github.com/python/cpython/commit/424023efee5b21567b4725015ef143b627112e3c - Fails: https://github.com/python/cpython/commit/288af845a32fd2a92e3b49738faf8f2de6a7bf7c -- components: Tests messages: 413786 nosy: sobolevn, vstinner priority: normal severity: normal status: open title: test_gdb started to fail on buildbot/s390x RHEL7 type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46834> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46815] Extra `DeprecationWarning` when running `lib2to3` tests
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29594 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31464 ___ Python tracker <https://bugs.python.org/issue46815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46815] Extra `DeprecationWarning` when running `lib2to3` tests
New submission from Nikita Sobolev : I first noticed it in the buildbot logs: ``` 0:24:42 load avg: 3.87 [430/431/1] test_lib2to3 passed (1 min 38 sec) :2: DeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+ ``` But, it also happens locally: ``` Β» ./python.exe Lib/test/test_lib2to3.py /Users/sobolev/Desktop/cpython/Lib/unittest/loader.py:350: DeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+ __import__(name) Refactor file: /Users/sobolev/Desktop/cpython/Lib/lib2to3/refactor.py ``` After my patch it is gone: ``` Β» ./python.exe Lib/test/test_lib2to3.py Refactor file: /Users/sobolev/Desktop/cpython/Lib/lib2to3/refactor.py ``` -- components: Tests messages: 413643 nosy: Jelle Zijlstra, benjamin.peterson, lukasz.langa, sobolevn priority: normal severity: normal status: open title: Extra `DeprecationWarning` when running `lib2to3` tests type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Change by Nikita Sobolev : -- type: -> behavior versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29565 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31430 ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Nikita Sobolev added the comment: I like this idea. `attrs` right now behave the same way (no default `__attrs_post_init__`: ``` >>> import attrs >>> @attrs.define ... class Some: ... x: int ... >>> @attrs.define ... class Other(Some): ...def __attrs_post_init__(self): ... super().__attrs_post_init__() ... self.x += 1 ... >>> Other(1) Traceback (most recent call last): File "", line 1, in File "", line 3, in __init__ File "", line 4, in __attrs_post_init__ AttributeError: 'super' object has no attribute '__attrs_post_init__' ``` I am attaching a simple patch. Alternative solution is to not merge this patch and recommend this instead: ``` def __post_init__(self): try: super().__post_init__() except AttributeError: pass ``` -- nosy: +sobolevn ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46465] Regression caused by CALL_FUNCTION specialization for C function calls (test_urllib fails when run multiple times)
Change by Nikita Sobolev : -- nosy: +sobolevn nosy_count: 7.0 -> 8.0 pull_requests: +29545 status: open -> pending pull_request: https://github.com/python/cpython/pull/31404 ___ Python tracker <https://bugs.python.org/issue46465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46709] test_urllib: testInterruptCaught() has a race condition and fails randomly
Change by Nikita Sobolev : -- pull_requests: +29544 pull_request: https://github.com/python/cpython/pull/31404 ___ Python tracker <https://bugs.python.org/issue46709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46745] Typo in new PositionsIterator
Change by Nikita Sobolev : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46679] test.support.wait_process ignores timeout argument
Change by Nikita Sobolev : -- nosy: +sobolevn nosy_count: 1.0 -> 2.0 pull_requests: +29486 pull_request: https://github.com/python/cpython/pull/31274 ___ Python tracker <https://bugs.python.org/issue46679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44525] Implement CALL_FUNCTION adaptive interpreter optimizations
Change by Nikita Sobolev : -- nosy: +sobolevn nosy_count: 4.0 -> 5.0 pull_requests: +29437 pull_request: https://github.com/python/cpython/pull/31273 ___ Python tracker <https://bugs.python.org/issue44525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46711] test_logging: test_post_fork_child_no_deadlock() failed with timeout on AMD64 Arch Linux Asan Debug 3.10
Change by Nikita Sobolev : -- keywords: +patch nosy: +sobolevn nosy_count: 1.0 -> 2.0 pull_requests: +29436 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31274 ___ Python tracker <https://bugs.python.org/issue46711> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46709] test_urllib: testInterruptCaught() has a race condition and fails randomly
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29435 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31273 ___ Python tracker <https://bugs.python.org/issue46709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46709] test_urllib: testInterruptCaught() has a race condition and fails randomly
Nikita Sobolev added the comment: Other tests are also affected: - `./python.exe -m test -m unittest.test.test_break.TestBreakDefaultIntHandler.testSecondInterrupt test_unittest -F` - `./python.exe -m test -m unittest.test.test_break.TestBreakDefaultIntHandler.testTwoResults test_unittest -F` - `./python.exe -m test -m unittest.test.test_break.TestBreakDefaultIntHandler.testHandlerReplacedButCalled test_unittest -F` - etc I think that we need a universal solution, I am going to write a helper method and add it to all tests there. -- ___ Python tracker <https://bugs.python.org/issue46709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46709] test_urllib: testInterruptCaught() has a race condition and fails randomly
Nikita Sobolev added the comment: I think this might be a side effect of https://docs.python.org/3/library/signal.html#execution-of-python-signal-handlers > A Python signal handler does not get executed inside the low-level (C) signal > handler. Instead, the low-level signal handler sets a flag which tells the > virtual machine to execute the corresponding Python signal handler at a later > point(for example at the next bytecode instruction). This has consequences -- ___ Python tracker <https://bugs.python.org/issue46709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46709] test_urllib: testInterruptCaught() has a race condition and fails randomly
Nikita Sobolev added the comment: I am trying to debug this. Several intersting notes: 1. `time.sleep()` does not help 2. It always fails on `8`th turn 3. Changing `self.assertTrue(result.shouldStop)` to ``` msg = f'{type(result)} {vars(result)}' self.assertTrue(result.shouldStop, msg) ``` fixes the problem. -- nosy: +sobolevn ___ Python tracker <https://bugs.python.org/issue46709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46430] intern strings in deepfrozen modules
Change by Nikita Sobolev : -- nosy: +sobolevn nosy_count: 3.0 -> 4.0 pull_requests: +29417 pull_request: https://github.com/python/cpython/pull/31248 ___ Python tracker <https://bugs.python.org/issue46430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45863] tarfile zeroes ustar header fields unnecessarily
Change by Nikita Sobolev : -- nosy: +sobolevn nosy_count: 4.0 -> 5.0 pull_requests: +29416 pull_request: https://github.com/python/cpython/pull/31248 ___ Python tracker <https://bugs.python.org/issue45863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46689] `list(FunctionType(a.gi_code, {})(0))` crashes Python
New submission from Nikita Sobolev : Here's the simplest reproduction: ``` from types import FunctionType a = (x for x in [1]) list(FunctionType(a.gi_code, {})(0)) ``` I understand that the code above does not make much sense, but I still think it should not crash. Demo: ``` Β» PYTHONFAULTHANDLER=1 ./python.exe Python 3.11.0a5+ (heads/issue-46647-dirty:88819357a5, Feb 5 2022, 18:19:59) [Clang 11.0.0 (clang-1100.0.33.16)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from types import FunctionType >>> a = (x for x in [1]) >>> list(FunctionType(a.gi_code, {})(0)) Fatal Python error: Segmentation fault Current thread 0x000112ece5c0 (most recent call first): File "", line 1 in File "", line 1 in [1]22662 segmentation fault PYTHONFAULTHANDLER=1 ./python.exe ``` I can reproduce this on 3.9 and 3.10 as well. -- components: Interpreter Core messages: 412897 nosy: sobolevn priority: normal severity: normal status: open title: `list(FunctionType(a.gi_code, {})(0))` crashes Python type: crash versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46685] Add additional tests for new features in `typing.py`
Change by Nikita Sobolev : -- pull_requests: +29394 pull_request: https://github.com/python/cpython/pull/31223 ___ Python tracker <https://bugs.python.org/issue46685> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46685] Add additional tests for new features in `typing.py`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29392 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31222 ___ Python tracker <https://bugs.python.org/issue46685> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46685] Add additional tests for new features in `typing.py`
New submission from Nikita Sobolev : New features (like `Self` type and `Never` type), in my opinion, require some extra testing. Things that were not covered: - Inheritance from `Self`, only `type(Self)` is covered: https://github.com/python/cpython/blob/c018d3037b5b62e6d48d5985d1a37b91762fbffb/Lib/test/test_typing.py#L193-L196 - Equality and non-equality for `Self` and `Never`. We should be sure that `NoReturn` is not equal to `Never`, but they are equal to themselfs - `get_type_hints` with `Never` - `get_origin` with `Self` and `Never` types, it should return `None` for both cases - (not exactly related) I've also noticed that this line is not covered at all: https://github.com/python/cpython/blob/c018d3037b5b62e6d48d5985d1a37b91762fbffb/Lib/typing.py#L725 Maybe there are some other cases? I will send a PR :) -- components: Tests messages: 412865 nosy: AlexWaygood, Jelle Zijlstra, gvanrossum, kj, sobolevn priority: normal severity: normal status: open title: Add additional tests for new features in `typing.py` type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46685> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46647] `test_functools` unexpected failures when C `_functoolsmodule` is missing
Nikita Sobolev added the comment: > Or maybe you have other cases to show the functools module will missing > unexpectly? No, I can't think of any :) Your argument about code churn also makes sense. But, if we ever are going to refactor this test module, this is something to remember of. Thanks everyone! -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46672] NameError in asyncio.gather when passing a invalid type as an arg with multiple awaitables
Change by Nikita Sobolev : -- keywords: +patch nosy: +sobolevn nosy_count: 3.0 -> 4.0 pull_requests: +29358 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31187 ___ Python tracker <https://bugs.python.org/issue46672> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46648] `test.test_urllib2.MiscTests.test_issue16464` flaky due to external connection
Change by Nikita Sobolev : -- pull_requests: +29357 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31186 ___ Python tracker <https://bugs.python.org/issue46648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46611] Improve coverage of `__instancecheck__` and `__subclasscheck__` methods in `typing.py`
Change by Nikita Sobolev : -- pull_requests: +29354 pull_request: https://github.com/python/cpython/pull/31182 ___ Python tracker <https://bugs.python.org/issue46611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46650] `priority` in `sched.scheduler` is not sufficiently tested
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29322 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31144 ___ Python tracker <https://bugs.python.org/issue46650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46650] `priority` in `sched.scheduler` is not sufficiently tested
New submission from Nikita Sobolev : Right now there only a single test to ensure `priority` works correctly in `scheduler`: https://github.com/python/cpython/blob/fea7290a0ecee09bbce571d4d10f5881b7ea3485/Lib/test/test_sched.py#L90-L97 It looks like it is not enough. Why? ``` for priority in [1, 2, 3, 4, 5]: z = scheduler.enterabs(0.01, priority, fun, (priority,)) scheduler.run() self.assertEqual(l, [1, 2, 3, 4, 5]) ``` This test does not actually test different priorities. It only tests that a direct one works correctly. But, this might be a pure coincidence that numbers match. They are spawned in this particular order. What if there are equal numbers? Like `[1, 2, 1]` I propose adding more examples to this test. PR is on its way. -- components: Tests messages: 412577 nosy: sobolevn priority: normal severity: normal status: open title: `priority` in `sched.scheduler` is not sufficiently tested type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46647] `test_functools` unexpected failures when C `_functoolsmodule` is missing
Nikita Sobolev added the comment: Cristian, in this case - is there a reason to keep `skipUnless(c_functools)` around? If we are sure that it is always available - then it should be always tested. We either should have: 1. Cleanly defined skips that work (this PR) 2. Unconditional coverage Or do you think that some middle-ground is possible? -- ___ Python tracker <https://bugs.python.org/issue46647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36019] test_urllib fail in s390x buildbots: http://www.example.com/
Nikita Sobolev added the comment: I can also reproduce it locally with: `./python.exe -m test -v test_urllib2 -m test_issue16464 -u network` I've opened a new issue for it: https://bugs.python.org/issue46648 -- ___ Python tracker <https://bugs.python.org/issue36019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46648] `test.test_urllib2.MiscTests.test_issue16464` started to fail
New submission from Nikita Sobolev : Today I've noticed that a lot of CI runs fail because of this test. Output: ``` == ERROR: test_issue16464 (test.test_urllib2.MiscTests) -- Traceback (most recent call last): File "/Users/sobolev/Desktop/cpython/Lib/contextlib.py", line 155, in __exit__ self.gen.throw(typ, value, traceback) ^ File "/Users/sobolev/Desktop/cpython/Lib/test/support/socket_helper.py", line 245, in transient_internet yield ^ File "/Users/sobolev/Desktop/cpython/Lib/test/test_urllib2.py", line 1799, in test_issue16464 opener.open(request, "1".encode("us-ascii")) File "/Users/sobolev/Desktop/cpython/Lib/urllib/request.py", line 525, in open response = meth(req, response) ^^^ File "/Users/sobolev/Desktop/cpython/Lib/urllib/request.py", line 634, in http_response response = self.parent.error( ^^ File "/Users/sobolev/Desktop/cpython/Lib/urllib/request.py", line 563, in error return self._call_chain(*args) ^^^ File "/Users/sobolev/Desktop/cpython/Lib/urllib/request.py", line 496, in _call_chain result = func(*args) ^^^ File "/Users/sobolev/Desktop/cpython/Lib/urllib/request.py", line 643, in http_error_default raise HTTPError(req.full_url, code, msg, hdrs, fp) ^^ urllib.error.HTTPError: HTTP Error 404: Not Found -- Ran 1 test in 0.448s FAILED (errors=1) /Users/sobolev/Desktop/cpython/Lib/test/support/__init__.py:705: ResourceWarning: unclosed gc.collect() ResourceWarning: Enable tracemalloc to get the object allocation traceback test test_urllib2 failed test_urllib2 failed (1 error) == Tests result: FAILURE == ``` I can also reproduce this failure locally with: ``` ./python.exe -m test -v test_urllib2 -m test_issue16464 -u network ``` Related https://bugs.python.org/issue36019 -- components: Tests messages: 412567 nosy: sobolevn priority: normal severity: normal status: open title: `test.test_urllib2.MiscTests.test_issue16464` started to fail type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36019] test_urllib fail in s390x buildbots: http://www.example.com/
Nikita Sobolev added the comment: `test.test_urllib2.MiscTests.test_issue16464` started to fail again: ``` == ERROR: test_issue16464 (test.test_urllib2.MiscTests) -- Traceback (most recent call last): File "/Users/runner/work/cpython/cpython/Lib/contextlib.py", line 155, in __exit__ self.gen.throw(typ, value, traceback) ^ File "/Users/runner/work/cpython/cpython/Lib/test/support/socket_helper.py", line 245, in transient_internet yield ^ File "/Users/runner/work/cpython/cpython/Lib/test/test_urllib2.py", line 1799, in test_issue16464 opener.open(request, "1".encode("us-ascii")) File "/Users/runner/work/cpython/cpython/Lib/urllib/request.py", line 525, in open response = meth(req, response) ^^^ File "/Users/runner/work/cpython/cpython/Lib/urllib/request.py", line 634, in http_response response = self.parent.error( ^^ File "/Users/runner/work/cpython/cpython/Lib/urllib/request.py", line 563, in error return self._call_chain(*args) ^^^ File "/Users/runner/work/cpython/cpython/Lib/urllib/request.py", line 496, in _call_chain result = func(*args) ^^^ File "/Users/runner/work/cpython/cpython/Lib/urllib/request.py", line 643, in http_error_default raise HTTPError(req.full_url, code, msg, hdrs, fp) ^^ urllib.error.HTTPError: HTTP Error 404: Not Found -- Ran 1 test in 0.093s ``` Link: https://github.com/python/cpython/runs/5077404591?check_suite_focus=true#step:7:705 Today I had like 3 or 4 different CI failures because of it. -- nosy: +sobolevn ___ Python tracker <https://bugs.python.org/issue36019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46647] `test_functools` unexpected failures when C `_functoolsmodule` is missing
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29318 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31141 ___ Python tracker <https://bugs.python.org/issue46647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46647] `test_functools` unexpected failures when C `_functoolsmodule` is missing
New submission from Nikita Sobolev : Reproduction steps: 1. Add to `Setup.local`: ``` *disabled* _functoolsmodule ``` 2. `.configure && make -j`. Then, ensure that this module is not available: ``` Β» ./python.exe -c 'import _functools' Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named '_functools' ``` 3. Run `test_functools`: ``` == ERROR: test_bad_cmp (test.test_functools.TestCmpToKeyC) -- Traceback (most recent call last): File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 905, in test_bad_cmp key = self.cmp_to_key(cmp1) ^ TypeError: cmp_to_key() takes 1 positional argument but 2 were given == ERROR: test_cmp_to_key (test.test_functools.TestCmpToKeyC) -- Traceback (most recent call last): File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 869, in test_cmp_to_key key = self.cmp_to_key(cmp1) ^ TypeError: cmp_to_key() takes 1 positional argument but 2 were given == ERROR: test_cmp_to_key_arguments (test.test_functools.TestCmpToKeyC) -- Traceback (most recent call last): File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 885, in test_cmp_to_key_arguments key = self.cmp_to_key(mycmp=cmp1) ^^^ TypeError: cmp_to_key() got multiple values for argument 'mycmp' == ERROR: test_hash (test.test_functools.TestCmpToKeyC) -- Traceback (most recent call last): File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 941, in test_hash key = self.cmp_to_key(mycmp) ^^ TypeError: cmp_to_key() takes 1 positional argument but 2 were given == ERROR: test_obj_field (test.test_functools.TestCmpToKeyC) -- Traceback (most recent call last): File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 920, in test_obj_field key = self.cmp_to_key(mycmp=cmp1) ^^^ TypeError: cmp_to_key() got multiple values for argument 'mycmp' == ERROR: test_sort_int (test.test_functools.TestCmpToKeyC) -- Traceback (most recent call last): File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 926, in test_sort_int self.assertEqual(sorted(range(5), key=self.cmp_to_key(mycmp)), ^^ TypeError: cmp_to_key() takes 1 positional argument but 2 were given == ERROR: test_sort_int_str (test.test_functools.TestCmpToKeyC) -- Traceback (most recent call last): File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 934, in test_sort_int_str values = sorted(values, key=self.cmp_to_key(mycmp)) ^^ TypeError: cmp_to_key() takes 1 positional argument but 2 were given == ERROR: test_pickle (test.test_functools.TestPartialC) -- Traceback (most recent call last): File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 258, in test_pickle f_copy = pickle.loads(pickle.dumps(f, proto)) ^^ _pickle.PicklingError: Can't pickle : it's not the same object as functools.partial == ERROR: test_recursive_pickle (test.test_functools.TestPartialC) -- Traceback (most recent call last): File "/Users/sobolev/Desktop/cpython/Lib/test/test_functools.py", line 343, in test_recursive_pickle pickle.dumps(f, proto) ^^ _pickle.PicklingError: Can't pickle : it's not t
[issue46646] `address` arg can be `bytes` for `ip_*` functions in `ipaddress` module
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29317 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31139 ___ Python tracker <https://bugs.python.org/issue46646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46646] `address` arg can be `bytes` for `ip_*` functions in `ipaddress` module
New submission from Nikita Sobolev : Right now the docs say: > ipaddress.ip_interface(address) > Return an IPv4Interface or IPv6Interface object depending on the IP address > passed as argument. **address is a string or integer** representing the IP > address. Either IPv4 or IPv6 addresses may be supplied; integers less than > 2**32 will be considered to be IPv4 by default. A ValueError is raised if > address does not represent a valid IPv4 or IPv6 address. Note the `address is a string or integer` part. But, this is not true. Counter example: ``` >>> import ipaddress >>> ipaddress.ip_interface(b'') IPv4Interface('48.48.48.48/32') >>> ipaddress.ip_interface(b'') IPv4Interface('49.49.49.49/32') ``` So, packed version that accepts `bytes`, should be also mentioned. For `ip_address` types are not mentioned: > ipaddress.ip_address(address) > Return an IPv4Address or IPv6Address object depending on the IP address > passed as argument. Either IPv4 or IPv6 addresses may be supplied; integers > less than 2**32 will be considered to be IPv4 by default. A ValueError is > raised if address does not represent a valid IPv4 or IPv6 address. I will send a PR with proposed changes. -- assignee: docs@python components: Documentation messages: 412562 nosy: docs@python, sobolevn priority: normal severity: normal status: open title: `address` arg can be `bytes` for `ip_*` functions in `ipaddress` module type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46646> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46611] Improve coverage of `__instancecheck__` and `__subclasscheck__` methods in `typing.py`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29262 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31078 ___ Python tracker <https://bugs.python.org/issue46611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46611] Improve coverage of `__instancecheck__` and `__subclasscheck__` methods in `typing.py`
Change by Nikita Sobolev : -- nosy: +AlexWaygood, gvanrossum, kj ___ Python tracker <https://bugs.python.org/issue46611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46611] Improve coverage of `__instancecheck__` and `__subclasscheck__` methods in `typing.py`
New submission from Nikita Sobolev : There are several problem reported by coverage: 1. This line is never reached in `_SpecialGenericAlias.__subclasscheck__`: https://github.com/python/cpython/blob/08f8301b21648d58d053e1a513db8ed32fbf37dd/Lib/typing.py#L1140 2. `__instancecheck__` and `__subclasscheck__` for `_UnionGenericAlias` are not covered at all: https://github.com/python/cpython/blob/08f8301b21648d58d053e1a513db8ed32fbf37dd/Lib/typing.py#L1243-L1249 I suspect this happened because of `types.UnionType` / `typing.Union` duality I am going to add these today! By the way, this is the last coverage issue in typing! π -- components: Library (Lib) messages: 412361 nosy: sobolevn priority: normal severity: normal status: open title: Improve coverage of `__instancecheck__` and `__subclasscheck__` methods in `typing.py` type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46610] assertCountEqual doesn't work as expected for dictionary elements
Change by Nikita Sobolev : -- components: +Library (Lib) versions: +Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46610] assertCountEqual doesn't work as expected for dictionary elements
New submission from Nikita Sobolev : @cansarigol, can you please specify what do you expect and how it works? -- nosy: +sobolevn ___ Python tracker <https://bugs.python.org/issue46610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46603] `typing._strip_annotations` is not fully covered
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29248 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31063 ___ Python tracker <https://bugs.python.org/issue46603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46603] `typing._strip_annotations` is not fully covered
New submission from Nikita Sobolev : Right now `coverage` says that this line is not covered at all: https://github.com/python/cpython/blob/bebaa95fd0f44babf8b6bcffd8f2908c73ca259e/Lib/typing.py#L1882 Considering how hard all these `types.UnionType` / `typing.Union` stuff is and that the logic with `reduce` and `operator.or_` is also quite complex, I think it is important to cover it. It actually took me some time to reach this line, but here's the test I came up with: ``` def test_get_type_hints_annotated_in_union(self): def with_union(x: int | list[Annotated[str, 'meta']]): ... self.assertEqual(get_type_hints(with_union), {'x': int | list[str]}) self.assertEqual( get_type_hints(with_union, include_extras=True), {'x': int | list[Annotated[str, 'meta']]}, ) ``` Note that direct `|` with `Annotated` does not work, because it triggers `_AnnotatedType.__or__`, which returns `typing.Union` and not `types.UnionType`. I will send a PR with it in a minute :) Any feedback is welcome! -- components: Library (Lib) messages: 412308 nosy: AlexWaygood, gvanrossum, kj, sobolevn priority: normal severity: normal status: open title: `typing._strip_annotations` is not fully covered type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46482] `typing.Annotation.__new__` is not covered
Nikita Sobolev added the comment: Thanks! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46571] Strange `@typing.no_type_check` behavior for class variables
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29224 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31042 ___ Python tracker <https://bugs.python.org/issue46571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46542] test_json and test_lib2to3 crash on s390x Fedora Clang 3.x buildbot
Change by Nikita Sobolev : -- nosy: -sobolevn ___ Python tracker <https://bugs.python.org/issue46542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46571] Strange `@typing.no_type_check` behavior for class variables
Nikita Sobolev added the comment: Ken Jin, Jelle, can you please share your ideas why `(2)` is better than `(1)`? -- ___ Python tracker <https://bugs.python.org/issue46571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46585] Should we re-export `PyObj_FromPtr` in `ctypes`?
New submission from Nikita Sobolev : After looking at https://github.com/python/cpython/blame/8fb36494501aad5b0c1d34311c9743c60bb9926c/Lib/ctypes/test/test_python_api.py#L5-L10 in https://bugs.python.org/issue46584 it seems that we should address this comment: ``` # This section should be moved into ctypes\__init__.py, when it's ready. from _ctypes import PyObj_FromPtr ``` by either: 1. Making `PyObj_FromPtr` public by re-exporting it from `ctypes` 2. Removing this comment Arguments for `(1)`: - It is quite widely used and there are a lot of articles mentioning it: https://www.programcreek.com/python/example/77012/_ctypes.PyObj_FromPtr and https://programtalk.com/python-examples/_ctypes.PyObj_FromPtr/ Basically, Google is filled with results. - It looks useful for educational purposes. I don't think that I am familiar with `ctypes`'s history well enough to make an educated dicision here. But, I would love to work on this after this decision is made :) -- components: ctypes messages: 412155 nosy: amaury.forgeotdarc, belopolsky, meador.inge, sobolevn, zach.ware priority: normal severity: normal status: open title: Should we re-export `PyObj_FromPtr` in `ctypes`? type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46584] Modernize `ctypes/test_python_api` by removing old version check
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29205 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31024 ___ Python tracker <https://bugs.python.org/issue46584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46584] Modernize `ctypes/test_python_api` by removing old version check
New submission from Nikita Sobolev : Right now Lib/ctypes/test/test_python_api.py has these lines: ``` if sys.version_info > (2, 4): c_py_ssize_t = c_size_t else: c_py_ssize_t = c_int ``` Source: https://github.com/python/cpython/blame/8fb36494501aad5b0c1d34311c9743c60bb9926c/Lib/ctypes/test/test_python_api.py#L13-L16 I think that there's no reason to keep code compat for python versions `<=2.3`. Other modules in CPython do refactor this by removing old and unused code, especially in tests. I propose to do the same here. -- components: Tests, ctypes messages: 412154 nosy: amaury.forgeotdarc, belopolsky, meador.inge, sobolevn, zach.ware priority: normal severity: normal status: open title: Modernize `ctypes/test_python_api` by removing old version check type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46581] _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with
Change by Nikita Sobolev : -- nosy: +sobolevn ___ Python tracker <https://bugs.python.org/issue46581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46583] Modernize `selectors.py` by removing unused `sys.version_info` check
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29204 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31023 ___ Python tracker <https://bugs.python.org/issue46583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46583] Modernize `selectors.py` by removing unused `sys.version_info` check
New submission from Nikita Sobolev : Right now `selectors.py` contains this check on module-level: ``` if sys.version_info >= (3, 5): ... ``` Source: https://github.com/python/cpython/blame/8fb36494501aad5b0c1d34311c9743c60bb9926c/Lib/selectors.py#L53 Learning from other modules, we tend to remove lines like this when some python version reaches EOL. And since 3.4 is not support for a long time now, this condition is always true. I propose to delete it. -- components: Library (Lib) messages: 412148 nosy: asvetlov, sobolevn, yselivanov priority: normal severity: normal status: open title: Modernize `selectors.py` by removing unused `sys.version_info` check type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46571] Strange `@typing.no_type_check` behavior for class variables
Nikita Sobolev added the comment: ## 1. What is documented? The docs makes this even more weird! > @typing.no_type_check > Decorator to indicate that annotations are not type hints. > This works as class or function decorator. With a class, it applies > recursively to all methods defined in that class (but not to methods defined > in its superclasses or subclasses). > This mutates the function(s) in place. https://docs.python.org/3/library/typing.html#typing.no_type_check Docs do not mention modifing nested classes at all! So, it looks like the `(1)` solution. ## 2. What does it do now? It modifies nested types, even ones used in assignments. ## 3. How is that used by runtime type inspectors? I've made a little research: 1. Hypothesis (I help with maintaining its typing API) does not support `@no_type_check` at all: https://github.com/HypothesisWorks/hypothesis/issues/3225 2. Pydantic, looks like `@no_type_check` does not change anything at all. ``` from pydantic import BaseModel from typing import no_type_check @no_type_check # the same with and without this decorator class MyModel(BaseModel): a: int print(MyModel(a=1)) # ok print(MyModel(a='1a')) # ok # pydantic.error_wrappers.ValidationError: 1 validation error for MyModel # a: value is not a valid integer (type=type_error.integer) ``` So, it always tries to coerce types. Docs: https://pydantic-docs.helpmanual.io/usage/types/ They also use it inside their own code-base: https://github.com/samuelcolvin/pydantic/search?q=no_type_check Probably for `mypy` to be happy. 3. `dataclasses` and `attrs` - nothing changes. Both do not use neither `@no_type_check` nor `get_type_hints` inside. Attrs: https://github.com/python-attrs/attrs/search?q=get_type_hints 4. Beartype: https://github.com/beartype/beartype > We've verified that @beartype reduces to the identity decorator when > decorating unannotated callables. That's but the tip of the iceberg, though. > @beartype unconditionally reduces to a noop when: > The decorated callable is itself decorated by the PEP 484-compliant > @typing.no_type_check decorator. So, as far as I understand, they only have `@no_type_check` support for callables. Related test: https://github.com/beartype/beartype/blob/50b213f315ecf97ea6a42674defe474b8f5d7203/beartype_test/a00_unit/a00_util/func/pep/test_utilpep484func.py So, to conclude, some project might still rely on current behavior that nested types are also implicitly marked as `@no_type_check`, but I cannot find any solid proof for it. The noticable thing is that this never came up before in ~6 years while this logic exists: https://github.com/python/cpython/blame/8fb36494501aad5b0c1d34311c9743c60bb9926c/Lib/typing.py#L1969-L1970 It helps to prove my point: probably, no one uses it. ## 3. How is that used by runtime type inspectors? ## 4. What would be most useful to runtime type inspectors? With all the information I gathered, I've changed my opinion :) Now I think that we should drop the part with modifing nested types at all (`(1)` solution). Only a type with `@no_type_check` should be modified. This is what docs say. This will also solve the original problem. Even if someone relies on current behavior: the fix is not hard, just add `@no_type_check` to nested types as well. So, do others have any objections / comments / feedback? :) -- ___ Python tracker <https://bugs.python.org/issue46571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46571] Strange `@typing.no_type_check` behavior for class variables
Change by Nikita Sobolev : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue46571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46571] Strange `@typing.no_type_check` behavior for class variables
New submission from Nikita Sobolev : I was working on improving coverage and test quality of `typing.py`, when I saw that `@no_type_check` is quite strange. Let's dive into this! ## Everything is correct We will start with a basic example, that illustrates that everything works fine: ``` from typing import no_type_check, get_type_hints class A: x: int = 1 class B: y: str = 'a' print(get_type_hints(A)) # ok: {'x': } print(get_type_hints(B)) # ok: {'y': } ``` Ok, let's move on. ## Adding `@no_type_check` Now, adding `@no_type_check` to `B` will make the result of `get_type_hints()` call on it - an empty `dict`: ``` from typing import no_type_check, get_type_hints class A: x: int = 1 @no_type_check class B: y: str = 'a' print(get_type_hints(A)) # ok: {'x': } print(get_type_hints(B)) # ok: {} ``` This is still ok. ## Broken? And now we can add some class-level constant to `B`, like `delegate` to show how it breaks `A`: ``` from typing import no_type_check, get_type_hints class A: x: int = 1 @no_type_check class B: y: str = 'a' delegate = A # adding this line will make `A` to have `__no_type_check__` as well print(get_type_hints(A)) # {}, wait, what? print(get_type_hints(B)) # {}, ok ``` Why is that important? It introduces an unfortunate side-effect that can make some totally unrelated (!) class completely ignore `get_type_hints()` and break things like `pydantic`, `beartype`, `attrs, etc that rely on type hints. By adding a class-level assignment to a class that has `@no_type_check` or other `no_type_check_decorator`. Why does this happen? It happens because `no_type_check` has this logic: ``` if isinstance(arg, type): arg_attrs = arg.__dict__.copy() for attr, val in arg.__dict__.items(): if val in arg.__bases__ + (arg,): arg_attrs.pop(attr) for obj in arg_attrs.values(): if isinstance(obj, types.FunctionType): obj.__no_type_check__ = True if isinstance(obj, type): no_type_check(obj) ``` Source: https://github.com/python/cpython/blob/8b1b27f1939cc4060531d198fdb09242f247ca7c/Lib/typing.py#L1952-L1975 As you can see above, we traverse all `__dict__` values of the given `class` and for some reason recurse into all nested types. I think that the original goal was to handle cases like: ``` @no_type_check class Outer: class Inner: ... ``` And now it also affects regular assignments. So, what can we do? 0. Nothing, it works correctly (I disagree) 1. Do not cover nested classes at all with `@no_type_check`, only cover methods 2. Only cover types that are **defined** in this class, like my `Inner` class example 3. Something else? I think that `(2)` is more inline with the currect implementation, so my vote is for it. I would like to implement this when we will have the final agreement :) -- components: Library (Lib) messages: 412073 nosy: AlexWaygood, Jelle Zijlstra, gvanrossum, kj, sobolevn priority: normal severity: normal status: open title: Strange `@typing.no_type_check` behavior for class variables versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46571> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46569] final note on StrEnum documentation incorrectly refers to int.__format__ instead of str.__format__
Change by Nikita Sobolev : -- keywords: +patch nosy: +sobolevn nosy_count: 3.0 -> 4.0 pull_requests: +29188 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31007 ___ Python tracker <https://bugs.python.org/issue46569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46565] Delete module-level loop variables when no longer needed
Nikita Sobolev added the comment: Thanks for the better wording, Terry! > Leaving loop variables available is an intended feature of python. Just to be clear: it sure is! But, sometimes we don't want to polute a global namespace with this variable. A common practice across CPython's source is to use `del` or comprehensions. That's exactly what my PR does: it finds places where people forgot to do that and adds a cleanup. > As it is, the PR applies a style standard on the stdlib that is not in PEP > 8. I recommend that you start by proposing an addition to PEP-8. Interesting idea! But, I think that this is an orthogonal non-blocking task, which might be much harder compared to this one :) I will add this to my backlog. > You might post the idea on pydev and ask how much and what sort of discussion > is needed. Good starting point, agreed! -- ___ Python tracker <https://bugs.python.org/issue46565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24398] Update test_capi to use test.support.script_helper
Change by Nikita Sobolev : -- nosy: +iritkatriel ___ Python tracker <https://bugs.python.org/issue24398> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46542] test_json and test_lib2to3 crash on s390x Fedora Clang 3.x buildbot
Change by Nikita Sobolev : -- nosy: +sobolevn nosy_count: 3.0 -> 4.0 pull_requests: +29174 pull_request: https://github.com/python/cpython/pull/30913 ___ Python tracker <https://bugs.python.org/issue46542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46565] Multiple modules leak `for` loop variables into module's namespace
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29173 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30993 ___ Python tracker <https://bugs.python.org/issue46565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46565] Multiple modules leak `for` loop variables into module's namespace
Change by Nikita Sobolev : -- nosy: +AlexWaygood ___ Python tracker <https://bugs.python.org/issue46565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46565] Multiple modules leak `for` loop variables into module's namespace
New submission from Nikita Sobolev : Some variables created as `for X in ...` leak into module's namespace, where the loop is defined. I wrote a simple `flake8` plugin to find names that are used in `ast.Module` in `ast.For`, but not under `if __name__ == '__main__'` and are not used in `del` afterwards. Here's what I got: - Lib/inspect.py:157 - Lib/locale.py:746 - Lib/sysconfig.py:186 - Lib/tokenize.py:141 - 151 - Lib/multiprocessing/process.py:427 - Lib/multiprocessing/managers.py:55 - Lib/json/encoder.py:30 - Lib/http/cookiejar.py:93 - Lib/email/contentmanager.py:73 - Lib/email/contentmanager.py:79 - Lib/email/contentmanager.py:247 - Lib/email/quoprimime.py:60 - Lib/email/quoprimime.py:149 - Lib/_compat_pickle - Lib/lib2to3/pgen2/grammar.py I think, that we need to remove these names. Why? 1. They complicate typeshed typing, we have to annotate them in typeshed, or write custom ignore rules for our test suite. Ref: https://github.com/python/typeshed/blob/56aa2088aada530400b6fdddf0f1d17ca3aaa86f/tests/stubtest_allowlists/py3_common.txt#L448 2. They are in `dir()`, example: ``` >>> import inspect >>> 'k' in dir(inspect) True ``` 3. They are listed in `help()`, let's use `json.encoder` as an example: ``` DATA ESCAPE = re.compile('[\\x00-\\x1f"\\b\\f\\n\\r\\t]') ESCAPE_ASCII = re.compile('(["]|[^\\ -~])') ESCAPE_DCT = {'\x00': r'\u', '\x01': r'\u0001', '\x02': r'\u0002',... HAS_UTF8 = re.compile(b'[\x80-\xff]') INFINITY = inf i = 31 ``` 4. We also have to exclude them sometimes in tests, like https://github.com/python/cpython/blob/db77bcd6092f3c174ae855522411ab83854d65a8/Lib/test/test_inspect.py#L111 I think that adding `del X` somewhere in these modules is a good thing: 1. Not hard to backport 2. Fixes multiple issues above 3. Does not store useless objects in memory 4. Does not confuse people 5. Some modules already delete unused intermediate vars, so it is not something new to CPython, for example: `multiprocessing.process` https://github.com/python/cpython/blob/db77bcd6092f3c174ae855522411ab83854d65a8/Lib/multiprocessing/process.py#L419 PR is on its way! -- components: Library (Lib) messages: 412006 nosy: sobolevn priority: normal severity: normal status: open title: Multiple modules leak `for` loop variables into module's namespace type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46530] `'thread_time'` is missing from `test_get_clock_info`
Nikita Sobolev added the comment: Thank you! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46550] __slots__ updates despite being read-only
Nikita Sobolev added the comment: It does not happen on `3.11` (main): ``` Python 3.11.0a4+ (heads/main-dirty:ef3ef6fa43, Jan 20 2022, 20:48:25) [Clang 11.0.0 (clang-1100.0.33.16)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... __slots__ = ('x',) ... >>> A.__slots__ += ('y',) >>> A.__slots__ ('x', 'y') >>> a = A() >>> a.__slots__ ('x', 'y') >>> a.__slots__ += ('z',) Traceback (most recent call last): File "", line 1, in AttributeError: 'A' object attribute '__slots__' is read-only >>> a.__slots__ ('x', 'y') ``` It also does not happen on `3.9`: ``` Python 3.9.9 (main, Dec 21 2021, 11:35:28) [Clang 11.0.0 (clang-1100.0.33.16)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class A: ... __slots__ = ('x',) ... >>> a = A() >>> a.__slots__ += ('y',) Traceback (most recent call last): File "", line 1, in AttributeError: 'A' object attribute '__slots__' is read-only >>> a.__slots__ ('x',) ``` -- nosy: +sobolevn ___ Python tracker <https://bugs.python.org/issue46550> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46546] `importlib.metadata.DeprecatedList` leaks `method_name` variable
Nikita Sobolev added the comment: Thanks, Jason! I've submitted https://github.com/python/importlib_metadata/pull/365 > What's the harm in leaving this attribute on a class that is itself standing > in for deprecated behavior and slated for removal? I think it does not do much harm, but there are several things that it affects: 1. Typing, we have to annotate it in typeshed, or write a custom ignore rule for our test suite 2. It is listed in `help()`: ``` | -- | Data and other attributes defined here: | | __hash__ = None | | method_name = 'sort' | | -- ``` 3. It is also in `dir(importlib.metadata.DeprecatedList)` So, even if we remove this class in some time, we still should care about it until the removal :) I am going to close this as "third party". -- resolution: -> third party stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46546> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46416] Direct invocation of `Lib/test/test_typing.py` fails
Change by Nikita Sobolev : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46547] `pydoc.Helper` leaks several `for` loop variables
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29136 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30957 ___ Python tracker <https://bugs.python.org/issue46547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46547] `pydoc.Helper` leaks several `for` loop variables
New submission from Nikita Sobolev : Here's the problem. `pydoc.Helper` is defined as: ``` class Helper: for topic, symbols_ in _symbols_inverse.items(): for symbol in symbols_: topics = symbols.get(symbol, topic) if topic not in topics: topics = topics + ' ' + topic symbols[symbol] = topics ``` Link: https://github.com/python/cpython/blob/08c0ed2d9c0d01ad1a5adc0787bc75e4e90cbb85/Lib/pydoc.py#L1877-L1882 It causes some unwanted consequences: `topic, symbols_, symbol` are leaking to the class's namespace. Example: ``` >>> import pydoc >>> pydoc.Helper.symbol 'J' >>> pydoc.Helper.topic 'COMPLEX' >>> pydoc.Helper.symbols_ ('j', 'J') ``` There's also `topics` var, but it is shadowed later. So, I propose deleting all intermediate variables right after the `for` loop. -- components: Library (Lib) messages: 411856 nosy: sobolevn priority: normal severity: normal status: open title: `pydoc.Helper` leaks several `for` loop variables type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46546] `importlib.metadata.DeprecatedList` leaks `method_name` variable
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29135 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30956 ___ Python tracker <https://bugs.python.org/issue46546> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46546] `importlib.metadata.DeprecatedList` leaks `method_name` variable
New submission from Nikita Sobolev : Right now in `DeprecatedList` there's a possibly unwated name leak of `method_name` here: https://github.com/python/cpython/blob/08c0ed2d9c0d01ad1a5adc0787bc75e4e90cbb85/Lib/importlib/metadata/__init__.py#L295-L308 ``` for method_name in [ '__setitem__', '__delitem__', 'append', 'reverse', 'extend', 'pop', 'remove', '__iadd__', 'insert', 'sort', ]: locals()[method_name] = _wrap_deprecated_method(method_name) ``` Example: ``` >>> import importlib >>> import importlib.metadata >>> importlib.metadata.DeprecatedList.method_name 'sort' ``` Right now `method_name` is unused, undocumented, and untested. My proposal is to add `del method_name` after the `for` loop, so it won't leak. -- components: Library (Lib) messages: 411855 nosy: brett.cannon, jaraco, sobolevn priority: normal severity: normal status: open title: `importlib.metadata.DeprecatedList` leaks `method_name` variable type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46546> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46544] `textwrap.TextWrapper` leaks two intermediate vars into class namespace
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29134 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30955 ___ Python tracker <https://bugs.python.org/issue46544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46545] `textwrap.TextWrapper` leaks two intermediate vars into class namespace
Nikita Sobolev added the comment: Oups, somehow I created two identical issues. Closing this one. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46545] `textwrap.TextWrapper` leaks two intermediate vars into class namespace
New submission from Nikita Sobolev : Right now this works: ``` >>> import textwrap >>> textwrap.TextWrapper.x ' ' >>> textwrap.TextWrapper.uspace 32 ``` This happens because of these lines: https://github.com/python/cpython/blame/606e496dd6e2ace298532da200169124c26ae0f2/Lib/textwrap.py#L66-L69 Notice that `uspace` and `x` are both undocumented, untested, and unused in our code. Similar variables in the same class body are then deleted from the scope: ``` wordsep_simple_re = re.compile(r'(%s+)' % whitespace) del whitespace ``` 1. https://github.com/python/cpython/blame/606e496dd6e2ace298532da200169124c26ae0f2/Lib/textwrap.py#L99 2. https://github.com/python/cpython/blame/606e496dd6e2ace298532da200169124c26ae0f2/Lib/textwrap.py#L106 I propose to add `del x, uspace` as well. These two probably should not be leaking and should not be exposed. -- components: Library (Lib) messages: 411850 nosy: sobolevn priority: normal severity: normal status: open title: `textwrap.TextWrapper` leaks two intermediate vars into class namespace type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46544] `textwrap.TextWrapper` leaks two intermediate vars into class namespace
New submission from Nikita Sobolev : Right now this works: ``` >>> import textwrap >>> textwrap.TextWrapper.x ' ' >>> textwrap.TextWrapper.uspace 32 ``` This happens because of these lines: https://github.com/python/cpython/blame/606e496dd6e2ace298532da200169124c26ae0f2/Lib/textwrap.py#L66-L69 Notice that `uspace` and `x` are both undocumented, untested, and unused in our code. Similar variables in the same class body are then deleted from the scope: ``` wordsep_simple_re = re.compile(r'(%s+)' % whitespace) del whitespace ``` 1. https://github.com/python/cpython/blame/606e496dd6e2ace298532da200169124c26ae0f2/Lib/textwrap.py#L99 2. https://github.com/python/cpython/blame/606e496dd6e2ace298532da200169124c26ae0f2/Lib/textwrap.py#L106 I propose to add `del x, uspace` as well. These two probably should not be leaking and should not be exposed. -- components: Library (Lib) messages: 411849 nosy: sobolevn priority: normal severity: normal status: open title: `textwrap.TextWrapper` leaks two intermediate vars into class namespace type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46531] Simplify exception handling in `doctest.py`
Nikita Sobolev added the comment: Fair enough! The only improvement is that we don't call `sys.exc_info` twice here: https://github.com/python/cpython/blob/6e5a193816e1bdf11f5fb78d620995fd6987ccf8/Lib/doctest.py#L2641-L2644 But, I think it is a minor thing. Looks like I've misunderstood the long time goal of `sys.exc_info` refactorings. Thanks a lot for the feedback! -- resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46531] Simplify exception handling in `doctest.py`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29095 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30916 ___ Python tracker <https://bugs.python.org/issue46531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46531] Simplify exception handling in `doctest.py`
New submission from Nikita Sobolev : Right now there are two places where `sys.exc_info()` calls are not required anymore: 1. https://github.com/python/cpython/blob/6e5a193816e1bdf11f5fb78d620995fd6987ccf8/Lib/doctest.py#L1352-L1353 2. https://github.com/python/cpython/blob/6e5a193816e1bdf11f5fb78d620995fd6987ccf8/Lib/doctest.py#L2640-L2641 There are also places where it is exposed as a part of public API (I am not going to change that, at least in this PR): - https://github.com/python/cpython/blob/6e5a193816e1bdf11f5fb78d620995fd6987ccf8/Lib/doctest.py#L1757 - https://github.com/python/cpython/blob/6e5a193816e1bdf11f5fb78d620995fd6987ccf8/Lib/doctest.py#L1262 And some private APIs (out of scope as well): - https://github.com/python/cpython/blob/6e5a193816e1bdf11f5fb78d620995fd6987ccf8/Lib/doctest.py#L244 PR is on its way! -- components: Library (Lib) messages: 411720 nosy: iritkatriel, sobolevn priority: normal severity: normal status: open title: Simplify exception handling in `doctest.py` type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46530] `'thread_time'` is missing from `test_get_clock_info`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29092 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30913 ___ Python tracker <https://bugs.python.org/issue46530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46530] `'thread_time'` is missing from `test_get_clock_info`
New submission from Nikita Sobolev : Right now here's how `test_get_clock_info` looks like: ``` def test_get_clock_info(self): clocks = ['monotonic', 'perf_counter', 'process_time', 'time'] for name in clocks: info = time.get_clock_info(name) #self.assertIsInstance(info, dict) self.assertIsInstance(info.implementation, str) self.assertNotEqual(info.implementation, '') self.assertIsInstance(info.monotonic, bool) self.assertIsInstance(info.resolution, float) # 0.0 < resolution <= 1.0 self.assertGreater(info.resolution, 0.0) self.assertLessEqual(info.resolution, 1.0) self.assertIsInstance(info.adjustable, bool) ``` It tests for out of five possible arguments to `time.get_clock_info`. Docs: https://docs.python.org/3/library/time.html#time.get_clock_info `'thread_time'` is missing for some reason. I think we should add it to the test. Link: https://github.com/python/cpython/blob/7cf285d82ec722d4225297366013e924805171f2/Lib/test/test_time.py#L559 PR is incoming. -- components: Tests messages: 411717 nosy: sobolevn priority: normal severity: normal status: open title: `'thread_time'` is missing from `test_get_clock_info` type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24398] Update test_capi to use test.support.script_helper
Change by Nikita Sobolev : -- nosy: +sobolevn nosy_count: 2.0 -> 3.0 pull_requests: +29091 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/30912 ___ Python tracker <https://bugs.python.org/issue24398> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46529] Improve test coverage of `Union` and `Optional` repr()
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29090 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30911 ___ Python tracker <https://bugs.python.org/issue46529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46529] Improve test coverage of `Union` and `Optional` repr()
New submission from Nikita Sobolev : There are several important cases that are missing from current `repr()` tests of `typing.Union` and `typing.Optional`: 1. This condition is not covered at all: `if args[0] is type(None):` https://github.com/python/cpython/blob/7cf285d82ec722d4225297366013e924805171f2/Lib/typing.py#L1236 3. `repr()` of `Union[str, None]` is not directly tested as well 3. `repr()` of `Union` with more that 2 parameters with `None` is not covered. This is an important corner case because of this condition: `if len(args) == 2:` https://github.com/python/cpython/blob/7cf285d82ec722d4225297366013e924805171f2/Lib/typing.py#L1235 I will send a PR with new assertions. -- components: Tests messages: 411715 nosy: gvanrossum, kj, sobolevn priority: normal severity: normal status: open title: Improve test coverage of `Union` and `Optional` repr() type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46523] Test suite skips failing tests when setUp[Class] fails
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29076 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30895 ___ Python tracker <https://bugs.python.org/issue46523> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46520] `ast.unparse` produces syntactically illegal code for identifiers that look like reserved words
Nikita Sobolev added the comment: I can confirm that it happens on all versions from 3.9 to 3.11 (main). ``` Python 3.9.9 (main, Dec 21 2021, 11:35:28) [Clang 11.0.0 (clang-1100.0.33.16)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import ast >>> ast.unparse(ast.parse("πππ = 1")) 'def = 1' >>> exec(ast.unparse(ast.parse("πππ = 1"))) # SyntaxError ``` ``` Python 3.11.0a4+ (heads/main-dirty:ef3ef6fa43, Jan 20 2022, 20:48:25) [Clang 11.0.0 (clang-1100.0.33.16)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import ast >>> ast.unparse(ast.parse("πππ = 1")) 'def = 1' >>> exec(ast.unparse(ast.parse("πππ = 1"))) # SyntaxError ``` -- nosy: +sobolevn versions: +Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46519] test_typing failing on branch 3.10
Nikita Sobolev added the comment: I filled a new issue: https://bugs.python.org/issue46523 -- ___ Python tracker <https://bugs.python.org/issue46519> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46523] Test suite skips failing tests
New submission from Nikita Sobolev : Here's what happened. We had an error in `test_typing.py`, which was silently ignored. ``` == ERROR: setUpClass (test.test_typing.NewTypeTests) -- Traceback (most recent call last): File "D:\a\cpython\cpython\lib\test\test_typing.py", line 3917, in setUpClass UserId = NewType('UserId', int) NameError: name 'NewType' is not defined -- Ran 396 tests in 0.085s FAILED (errors=1, skipped=1) test test_typing failed ``` Link: https://github.com/python/cpython/runs/4902363883?check_suite_focus=true But, later the suite runner tried to rerun it: ``` 0:09:12 load avg: 6.37 Re-running failed tests in verbose mode 0:09:12 load avg: 6.37 Re-running test_typing in verbose mode (matching: setUpClass) 1 re-run test: test_typing 1 test run no tests: test_typing ``` And since nothing matched `setUpClass` - no tests were executed and the CI went green instead of red. What can we do? 1. Only schedule real `test_` item to be rerun, fail for everything else 2. Convert `setupClass` failure into the whole class rerun 3. Other options? I would like to work on this, when we will decide which way is best. -- components: Tests messages: 411620 nosy: sobolevn priority: normal severity: normal status: open title: Test suite skips failing tests type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46523> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46519] test_typing failing on branch 3.10
Nikita Sobolev added the comment: These lines seem suspicious: ``` 0:09:12 load avg: 6.37 Re-running failed tests in verbose mode 0:09:12 load avg: 6.37 Re-running test_typing in verbose mode (matching: setUpClass) 1 re-run test: test_typing 1 test run no tests: test_typing ``` Probably this happens because the failure is in `setupClass` method, not in a test. When it try to rerun this, it does not do anything. And happily ends the suite. -- ___ Python tracker <https://bugs.python.org/issue46519> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46519] test_typing failing on branch 3.10
Nikita Sobolev added the comment: One of the first things to think of: maybe `NewTypeTests` are not executed at all on 3.10? -- ___ Python tracker <https://bugs.python.org/issue46519> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46396] `Concatenate` should not raise any semantic errors
Nikita Sobolev added the comment: I think that in case when we preserve the runtime checks, they should be covered by tests. Right now - they are not. So, I will switch my PR to the initial version with a new test case. Does this sound right? :) -- ___ Python tracker <https://bugs.python.org/issue46396> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46416] Direct invocation of `Lib/test/test_typing.py` fails
Nikita Sobolev added the comment: During this work some people have mentioned that they actually use `'__main__'` for local debugging of tests. I don't think that I am familiar enough with the existing workflow to make any educated decision :) ΠΏΠ½, 24 ΡΠ½Π². 2022 Π³. Π² 19:34, Christian Heimes : > > Christian Heimes added the comment: > > I noticed that you have been looking into the __main__ block of test > modules. Wouldn't it make more sense to just remove the __main__ and have > all tests go through regrtest? Everybody should use > >./python -m regrtest test_typing > > or the Windows equivalent to run typing tests. > > -- > nosy: +christian.heimes > > ___ > Python tracker > <https://bugs.python.org/issue46416> > ___ > -- ___ Python tracker <https://bugs.python.org/issue46416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46396] `Concatenate` should not raise any semantic errors
Nikita Sobolev added the comment: PR is updated, now `Concatenate` does not raise any semantic errors: https://github.com/python/cpython/pull/30619 -- components: +Library (Lib) -Tests title: Typing: test invalid usages of `Concatenate` -> `Concatenate` should not raise any semantic errors ___ Python tracker <https://bugs.python.org/issue46396> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46422] Why do we need `dis.Positions`?
Change by Nikita Sobolev : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46422> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46483] `pathlib.PurePath.__class_getitem__` does not return `GenericAlias`
Change by Nikita Sobolev : -- pull_requests: +29030 pull_request: https://github.com/python/cpython/pull/30848 ___ Python tracker <https://bugs.python.org/issue46483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46483] `pathlib.PurePath.__class_getitem__` does not return `GenericAlias`
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29009 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30822 ___ Python tracker <https://bugs.python.org/issue46483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46483] `pathlib.PurePath.__class_getitem__` does not return `GenericAlias`
New submission from Nikita Sobolev : After reviewing https://github.com/python/cpython/pull/30777 I had a chance to look through other definitions of `def __class_getitem__`. And I found that the only one left is: `pathlib.PurePath.__class_getitem__` All other definitions already have this form: `__class_getitem__ = classmethod(GenericAlias)`. I don't think that there's anything special about `PurePath` in this regard. So, I propose to make `__class_getitem__` to return `GenericAlias` as all other types do. Initial PR: https://github.com/python/cpython/pull/17498 PR is on its way. -- components: Library (Lib) messages: 411354 nosy: sobolevn priority: normal severity: normal status: open title: `pathlib.PurePath.__class_getitem__` does not return `GenericAlias` type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46482] `typing.Annotation.__new__` is not covered
Change by Nikita Sobolev : -- keywords: +patch pull_requests: +29008 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30821 ___ Python tracker <https://bugs.python.org/issue46482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46482] `typing.Annotation.__new__` is not covered
New submission from Nikita Sobolev : Right now no unit test covers this line: https://github.com/python/cpython/blob/51c3e28c8a163e58dc753765e3cc51d5a717e70d/Lib/typing.py#L1669-L1670 I will send a simple test for it. -- components: Tests messages: 411352 nosy: gvanrossum, kj, sobolevn priority: normal severity: normal status: open title: `typing.Annotation.__new__` is not covered type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44642] Union of a type and the typing module function
Nikita Sobolev added the comment: Looks like it was fixed indeed, `NewType` is now a class. And I cannot reproduce it even on `3.10`: ``` Python 3.10.0 (default, Nov 1 2021, 10:24:06) [Clang 11.0.0 (clang-1100.0.33.16)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import typing >>> int | typing.cast Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for |: 'type' and 'function' >>> int | typing.get_type_hints Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for |: 'type' and 'function' ``` -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44642> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com