[issue44895] refleak test failure in test_exceptions

Irit Katriel added the comment: I see it on Mac but not windows. Running the test with -v or adding prints makes the leak go away. I’m suspecting that one of the recursion tests fails to clear an exception or something like that. Removing any one of the tests makes it stop failing

[issue44895] refleak test failure in test_exceptions

STINNER Victor added the comment: I fail to reproduce the issue on Linux on the 3.10 branch. I interrupted the job after 20 minutes: $ ./python -m test -R 3:3 test_exceptions -m test_no_hang_on_context_chain_cycle2 -m test_recursion_normalizing_infinite_exception -m

[issue44895] refleak test failure in test_exceptions

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44895] refleak test failure in test_exceptions

Change by Dong-hee Na : -- nosy: +corona10 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44895] refleak test failure in test_exceptions

New submission from Irit Katriel : For background see https://bugs.python.org/issue33930#msg399403 iritkatriel@Irits-MBP cpython % repeat 10 ./python.exe -m test -R 3:3 test_exceptions -m test_no_hang_on_context_chain_cycle2 -m test_recursion_normalizing_infinite_exception -m

Re: some problems for an introductory python test

On Thu, Aug 12, 2021 at 9:23 AM Dennis Lee Bieber wrote: > > On Thu, 12 Aug 2021 06:15:28 +1000, Chris Angelico > declaimed the following: > > > >The default command interpreter and shell on OS/2 was fairly primitive > >by today's standards, and was highly compatible with the MS-DOS one, > >but

Re: some problems for an introductory python test

On Wed, 11 Aug 2021 09:27:38 -0300, Hope Rouselle declaimed the following: > >I wouldn't. This is all Python-stuff. The course chooses a language >like Python, but it is not trying to teach Python --- it is trying to >teach computer programming, that is, strategies in high-precision. >

Re: some problems for an introductory python test

On Thu, 12 Aug 2021 06:15:28 +1000, Chris Angelico declaimed the following: >The default command interpreter and shell on OS/2 was fairly primitive >by today's standards, and was highly compatible with the MS-DOS one, >but it also had the ability to run REXX scripts. REXX was *way* ahead >of

Re: some problems for an introductory python test

On Thu, Aug 12, 2021 at 7:25 AM Rob Cliffe via Python-list wrote: > > On 11/08/2021 19:10, MRAB wrote: > > On 2021-08-11 18:10, Wolfram Hinderer via Python-list wrote: > >> > >> > >> Am 11.08.2021 um 05:22 schrieb Terry Reedy: > >>> Python is a little looser about whitespace than one might expect

RE: some problems for an introductory python test

This conversation has, of course, veered away from the original question so I am starting afresh. My memory of the original question is about how one sets up a test for material covered in class or associated materials for what sounds like a beginner class. I am not sure whether this would

Re: some problems for an introductory python test

On 11/08/2021 19:10, MRAB wrote: On 2021-08-11 18:10, Wolfram Hinderer via Python-list wrote: Am 11.08.2021 um 05:22 schrieb Terry Reedy: Python is a little looser about whitespace than one might expect from reading 'normal' code when the result is unambiguous in that it cannot really mean

Re: some problems for an introductory python test

On Thu, Aug 12, 2021 at 5:00 AM Hope Rouselle wrote: > > Chris Angelico writes: > > > On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle > > wrote: > >> > >> Chris Angelico writes: > >> > >> [...] > >> > >> >> not disagreeing... and yeah I could have thought deeper about the > >> >> answer, but I

Re: some problems for an introductory python test

Chris Angelico writes: > On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle wrote: >> >> Chris Angelico writes: >> >> [...] >> >> >> not disagreeing... and yeah I could have thought deeper about the >> >> answer, but I still think "notthing has been OOP" -> "yes it has, they >> >> just didn't

Re: some problems for an introductory python test

Chris Angelico writes: > On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle wrote: >> >> I totally agree with you but I didn't know that even numbers were like >> that in Python. In fact, I still don't quite believe it... >> >> >>> 2.__add__(3) >> SyntaxError: invalid syntax > > Yeah, that's

Re: some problems for an introductory python test

Greg Ewing writes: > On 11/08/21 3:22 pm, Terry Reedy wrote: >> Python is a little looser about whitespace than one might expect >> from reading 'normal' code when the result is unambiguous in that it >> cannot really mean anything other than what it does. >> >>> if3: print('yes!') >> yes! > >

Re: some problems for an introductory python test

On 11/08/21 3:22 pm, Terry Reedy wrote: Python is a little looser about whitespace than one might expect from reading 'normal' code when the result is unambiguous in that it cannot really mean anything other than what it does. >>> if3: print('yes!') yes! That may not be doing what you

Re: some problems for an introductory python test

Terry Reedy writes: > On 8/10/2021 5:27 PM, Hope Rouselle wrote: >> Terry Reedy writes: >> >>> On 8/10/2021 9:15 AM, Hope Rouselle wrote: >>> 2.__add__(3) SyntaxError: invalid syntax But then I tried: >>> (2).__add__(3) 5 >>> >>> Add a space is easier. >> 2

Re: some problems for an introductory python test

On 2021-08-11 18:10, Wolfram Hinderer via Python-list wrote: Am 11.08.2021 um 05:22 schrieb Terry Reedy: Python is a little looser about whitespace than one might expect from reading 'normal' code when the result is unambiguous in that it cannot really mean anything other than what it does. 

Re: some problems for an introductory python test

Am 11.08.2021 um 05:22 schrieb Terry Reedy: Python is a little looser about whitespace than one might expect from reading 'normal' code when the result is unambiguous in that it cannot really mean anything other than what it does.  Two other examples: >>> if3: print('yes!') yes! >>> [0] 

Re: some problems for an introductory python test

On 8/10/2021 5:27 PM, Hope Rouselle wrote: Terry Reedy writes: On 8/10/2021 9:15 AM, Hope Rouselle wrote: 2.__add__(3) SyntaxError: invalid syntax But then I tried: (2).__add__(3) 5 Add a space is easier. 2 .__add__(3) 5 Hah. That's brilliant! So cool. Python is a little

Re: some problems for an introductory python test

Terry Reedy writes: > On 8/10/2021 9:15 AM, Hope Rouselle wrote: > 2.__add__(3) >> SyntaxError: invalid syntax >> But then I tried: >> > (2).__add__(3) >> 5 > > Add a space is easier. 2 .__add__(3) > 5 Hah. That's brilliant! So cool. --

Re: some problems for an introductory python test

Chris Angelico writes: > On Wed, Aug 11, 2021 at 4:14 AM Hope Rouselle wrote: >> >> Chris Angelico writes: >> >> > On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle >> > wrote: >> >> I came up with the following question. Using strings of length 5 >> >> (always), write a procedure histogram(s)

Re: some problems for an introductory python test

On 8/10/2021 9:15 AM, Hope Rouselle wrote: 2.__add__(3) SyntaxError: invalid syntax But then I tried: (2).__add__(3) 5 Add a space is easier. >>> 2 .__add__(3) 5 >>> -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list

Re: some problems for an introductory python test

On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle wrote: > > Chris Angelico writes: > > [...] > > >> not disagreeing... and yeah I could have thought deeper about the > >> answer, but I still think "notthing has been OOP" -> "yes it has, they > >> just didn't realize it" was worth mentioning > > >

Re: some problems for an introductory python test

On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle wrote: > > I totally agree with you but I didn't know that even numbers were like > that in Python. In fact, I still don't quite believe it... > > >>> 2.__add__(3) > SyntaxError: invalid syntax Yeah, that's because "2." looks like the beginning of a

Re: some problems for an introductory python test

On Wed, Aug 11, 2021 at 4:14 AM Hope Rouselle wrote: > > Chris Angelico writes: > > > On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle > > wrote: > >> I came up with the following question. Using strings of length 5 > >> (always), write a procedure histogram(s) that consumes a string and > >>

Re: some problems for an introductory python test

Mats Wichmann writes: > On 8/9/21 3:07 PM, Hope Rouselle wrote: >> I'm looking for questions to put on a test for students who never had >> any experience with programming, but have learned to use Python's >> procedures, default arguments, if-else, strings, tuples, list

Re: some problems for an introductory python test

Chris Angelico writes: [...] >> not disagreeing... and yeah I could have thought deeper about the >> answer, but I still think "notthing has been OOP" -> "yes it has, they >> just didn't realize it" was worth mentioning > > Oh yes, absolutely agree. At the same time, inside the machine

Re: some problems for an introductory python test

Chris Angelico writes: > On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle wrote: >> I came up with the following question. Using strings of length 5 >> (always), write a procedure histogram(s) that consumes a string and >> produces a dictionary whose keys are each substrings (of the string) of >>

Re: some problems for an introductory python test

On Tue, Aug 10, 2021 at 1:41 PM Mats Wichmann wrote: > > > On 8/9/21 6:34 PM, Chris Angelico wrote: > > > If you want to highlight the OOP nature of Python, rather than looking > > at magic methods, I'd first look at polymorphism. You can add a pair > > of integers; you can add a pair of tuples;

Re: some problems for an introductory python test

On 8/9/21 6:34 PM, Chris Angelico wrote: If you want to highlight the OOP nature of Python, rather than looking at magic methods, I'd first look at polymorphism. You can add a pair of integers; you can add a pair of tuples; you can add a pair of strings. Each one logically adds two things

Re: some problems for an introductory python test

On Tue, Aug 10, 2021 at 8:19 AM Mats Wichmann wrote: > Even if you do > > x = 2 + 3 > > you're actually creating an integer object with a value of 2, and > calling its add method to add the integer object with the value of 3 to > it. The syntax hides it, but in a way it's just convenience that it

Re: some problems for an introductory python test

On 8/9/21 3:07 PM, Hope Rouselle wrote: I'm looking for questions to put on a test for students who never had any experience with programming, but have learned to use Python's procedures, default arguments, if-else, strings, tuples, lists and dictionaries. (There's no OOP at all in this course

Re: some problems for an introductory python test

On Tue, Aug 10, 2021 at 7:25 AM Hope Rouselle wrote: > I came up with the following question. Using strings of length 5 > (always), write a procedure histogram(s) that consumes a string and > produces a dictionary whose keys are each substrings (of the string) of > length 1 and their

some problems for an introductory python test

I'm looking for questions to put on a test for students who never had any experience with programming, but have learned to use Python's procedures, default arguments, if-else, strings, tuples, lists and dictionaries. (There's no OOP at all in this course. Students don't even write ls.append

[issue44873] base64 RFC4648 test cases

New submission from Andrei Kulakov : RFC 4648 [1] has added a list of encoding test cases -- see section 10 of the RFC. It might be nice to add a test function that is a direct copy of these test cases. This will make conformance to this RFC clearer (actually right now we don't state

[issue42053] fwalk: incorrect boolean test for non-fd arguments

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.11 -Python 3.9 ___ Python tracker ___

[issue42053] fwalk: incorrect boolean test for non-fd arguments

Serhiy Storchaka added the comment: New changeset 2b496e79293a8b80e8ba0e514e186b3b1467b64b by Serhiy Storchaka in branch 'main': bpo-42053: Remove misleading check in os.fwalk() (GH-27669) https://github.com/python/cpython/commit/2b496e79293a8b80e8ba0e514e186b3b1467b64b --

[issue42053] fwalk: incorrect boolean test for non-fd arguments

Change by Serhiy Storchaka : -- pull_requests: +26158 pull_request: https://github.com/python/cpython/pull/27669 ___ Python tracker ___

[issue42053] fwalk: incorrect boolean test for non-fd arguments

Serhiy Storchaka added the comment: I confirm that fwalk() does not support integer first argument. This check is misleading. -- nosy: +serhiy.storchaka ___ Python tracker

[issue44852] Add ability to wholesale silence DeprecationWarnings while running the test suite

Serhiy Storchaka added the comment: clear_ignored_deprecations() does not know whether filters were added in setUp(), setUpClass(), setUpModule() or just in a particular method. We should use teadDown*() or add*Cleanup() to clean up at appropriate level. --

[issue44852] Add ability to wholesale silence DeprecationWarnings while running the test suite

Łukasz Langa added the comment: Serhiy, if you take a look at the code, `clear_ignored_deprecations()` only clears the filters that were added by `ignore_deprecations_from()`. It doesn't touch other filters. Sure, we can abuse the context manager instead but this looks pretty busy: def

[issue44852] Add ability to wholesale silence DeprecationWarnings while running the test suite

Serhiy Storchaka added the comment: There are problems with clearing all ignored deprecation filters. We can want to ignore warnings in narrower or wider scope: per-method, per-class, per-module. We should use the warnings.catch_warnings() context manager for restoring filters in the

[issue44852] Add ability to wholesale silence DeprecationWarnings while running the test suite

Łukasz Langa added the comment: For example, all that's needed to silence the 220 new warnings in all asyncio tests, is adding this in Lib/test/test_asyncio/__init__.py: ``` def setUpModule(): support.ignore_deprecations_from("asyncio.base_events", like=r".

[issue44852] Add ability to wholesale silence DeprecationWarnings while running the test suite

Change by Łukasz Langa : -- keywords: +patch pull_requests: +26128 pull_request: https://github.com/python/cpython/pull/27634 ___ Python tracker ___

[issue44852] Add ability to wholesale silence DeprecationWarnings while running the test suite

but that created 220 new warnings when running test_asyncion in regression tests. Fixing them one by one would be both tedious, and would make the 3.9 branch forever conflicting with newer branches in many asyncio test files. In 3.11 there's a new round of deprecations raised in test_asyncio, making

[issue42053] fwalk: incorrect boolean test for non-fd arguments

Change by Hasan : -- pull_requests: -26038 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42053] fwalk: incorrect boolean test for non-fd arguments

Change by Hasan : -- pull_requests: +26039 pull_request: https://github.com/python/cpython/pull/27524 ___ Python tracker ___ ___

[issue42053] fwalk: incorrect boolean test for non-fd arguments

Change by Hasan : -- keywords: +patch nosy: +AliyevH nosy_count: 2.0 -> 3.0 pull_requests: +26038 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27523 ___ Python tracker

[issue42053] fwalk: incorrect boolean test for non-fd arguments

Andrei Kulakov added the comment: By the way I confirmed that fixing this doesn't break any tests (perhaps unsurprising ;) ) -- ___ Python tracker ___

[issue42053] fwalk: incorrect boolean test for non-fd arguments

Andrei Kulakov added the comment: dubiousjim: I agree, it should be `and` or have the form `not (isinstance(..) or hasattr(..))`. If you would like to make the patch, I can review. -- nosy: +andrei.avk ___ Python tracker

[issue44515] contextlib test incompatibility with non-refcounted GC

Łukasz Langa added the comment: Thanks, Nick! ✨  ✨ -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue44515] contextlib test incompatibility with non-refcounted GC

Łukasz Langa added the comment: New changeset 0ea5e0d792a85b435ef299319dcd52e59f535cb1 by Miss Islington (bot) in branch '3.10': bpo-44515: handle non-refcounted GC in contextlib tests (GH-26910) (GH-27379) https://github.com/python/cpython/commit/0ea5e0d792a85b435ef299319dcd52e59f535cb1

[issue44515] contextlib test incompatibility with non-refcounted GC

Change by miss-islington : -- nosy: +miss-islington nosy_count: 2.0 -> 3.0 pull_requests: +25914 pull_request: https://github.com/python/cpython/pull/27379 ___ Python tracker

[issue44515] contextlib test incompatibility with non-refcounted GC

Łukasz Langa added the comment: New changeset a2c45e5bcf9d3dfff9f2699dbc161489897616b5 by Nick Coghlan in branch 'main': bpo-44515: handle non-refcounted GC in contextlib tests (GH-26910) https://github.com/python/cpython/commit/a2c45e5bcf9d3dfff9f2699dbc161489897616b5 -- nosy:

[issue44708] Regression tests with -w should only re-run affected test methods, not the entire file

Change by Łukasz Langa : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue44708] Regression tests with -w should only re-run affected test methods, not the entire file

Łukasz Langa added the comment: New changeset 0f55d21212a0fb6dec4479eb76249ab2b54e57a3 by Łukasz Langa in branch '3.9': [3.9] bpo-44708: Only re-run test methods that match names of previously failing test methods (GH-27287) (GH-27293) https://github.com/python/cpython/commit

[issue44708] Regression tests with -w should only re-run affected test methods, not the entire file

Change by Łukasz Langa : -- pull_requests: +25836 pull_request: https://github.com/python/cpython/pull/27293 ___ Python tracker ___

[issue44708] Regression tests with -w should only re-run affected test methods, not the entire file

Łukasz Langa added the comment: New changeset 9608719e12b14087c1cb34f77c847974442cd6e7 by Miss Islington (bot) in branch '3.10': bpo-44708: Only re-run test methods that match names of previously failing test methods (GH-27287) (GH-27290) https://github.com/python/cpython/commit

[issue44708] Regression tests with -w should only re-run affected test methods, not the entire file

Change by miss-islington : -- nosy: +miss-islington nosy_count: 2.0 -> 3.0 pull_requests: +25832 pull_request: https://github.com/python/cpython/pull/27290 ___ Python tracker

[issue44708] Regression tests with -w should only re-run affected test methods, not the entire file

Łukasz Langa added the comment: New changeset f1afef5e0d93d66fbf3c9aaeab8b3b8da9617583 by Łukasz Langa in branch 'main': bpo-44708: Only re-run test methods that match names of previously failing test methods (GH-27287) https://github.com/python/cpython/commit

[issue44708] Regression tests with -w should only re-run affected test methods, not the entire file

Change by Łukasz Langa : -- keywords: +patch pull_requests: +25829 pull_request: https://github.com/python/cpython/pull/27287 ___ Python tracker ___

[issue44708] Regression tests with -w should only re-run affected test methods, not the entire file

New submission from Łukasz Langa : When the CPython test suite re-runs a flaky failed test, it doesn’t actually re-run just that failed test but the entire test file. The most common case for flaky tests is when networking, threading, or multiprocessing is involved. Frustratingly those

[issue10572] Move test sub-packages to Lib/test

Brett Cannon added the comment: > After so long a reason came up that prevents the movement of tests of ctypes, > lib2to3, and idlelib (which even continues in the same folder, only the > nomenclature was changed)? Time and energy. -- ___ Python

[issue44650] Move test_futures files*.py into a subdirectory of Lib/test

Irit Katriel added the comment: A patch awaiting review since 2012 is not exactly the same as "the issue was accepted". -- ___ Python tracker ___

[issue44650] Move test_futures files*.py into a subdirectory of Lib/test

Leonardo Freua added the comment: Definitely not the same kind of reorganization! In issue44573 what was proposed was the reorganization of the data files used in the tests. And what I'm proposing now is equivalent to what was proposed in issue15907 (and there it was accepted, there is even

[issue15907] move doctest test-data files into a subdirectory of Lib/test

Change by Irit Katriel : -- resolution: -> not a bug stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue44650] Move test_futures files*.py into a subdirectory of Lib/test

Irit Katriel added the comment: This kind of reorg was recently rejected in issue44573. -- nosy: +iritkatriel resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue15907] move doctest test-data files into a subdirectory of Lib/test

Irit Katriel added the comment: This kind of reorg was recently rejected in issue44573, while this issue being open inspired similar initiative (eg issue44650). For those reasons I am closing this. -- ___ Python tracker

[issue44650] Move test_futures files*.py into a subdirectory of Lib/test

Leonardo Freua added the comment: List of files: test_future.py test_future3.py test_future4.py test_future5.py Obs.: In fact there are 5 files, since the number 2 doesn't exist. -- ___ Python tracker

[issue44650] Move test_futures files* into a subdirectory of Lib/test

Change by Leonardo Freua : -- components: +Library (Lib), Tests type: -> enhancement versions: +Python 3.11 ___ Python tracker ___

[issue44650] Move test_futures files*.py into a subdirectory of Lib/test

Change by Leonardo Freua : -- title: Move test_futures files* into a subdirectory of Lib/test -> Move test_futures files*.py into a subdirectory of Lib/test ___ Python tracker <https://bugs.python.org/issu

[issue44650] Move test_futures files* into a subdirectory of Lib/test

New submission from Leonardo Freua : There are currently 6 files referring to __future__ tests, these are in the root directory Lib/test. It would be interesting to move them to a directory called Lib/test/test_future. This change could contribute to the organization of the tests that have

[issue10572] Move test sub-packages to Lib/test

Leonardo Freua added the comment: After so long a reason came up that prevents the movement of tests of ctypes, lib2to3, and idlelib (which even continues in the same folder, only the nomenclature was changed)? -- nosy: +Leonardofreua ___ Python

[issue44573] Organize some data files in the Lib/test directory

Change by Raymond Hettinger : -- resolution: -> not a bug status: open -> closed ___ Python tracker ___ ___ Python-bugs-list

[issue44573] Organize some data files in the Lib/test directory

Change by Leonardo Freua : -- status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44573] Organize some data files in the Lib/test directory

Change by Leonardo Freua : -- stage: -> resolved status: open -> closed type: -> enhancement ___ Python tracker ___ ___

[issue44573] Organize some data files in the Lib/test directory

Srinivas Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) added the comment: +1 for Raymond's comment. -- nosy: +thatiparthy ___ Python tracker ___

[issue44586] unittest requires __init__.py for test discovery

Inada Naoki added the comment: And https://dev.to/methane/don-t-omit-init-py-3hga too. -- nosy: +methane ___ Python tracker ___

[issue44573] Organize some data files in the Lib/test directory

Raymond Hettinger added the comment: In practice, this hasn't been an issue. I recommend leaving it alone. Adding more directories is also a nuisance and doesn't really make anyone's life better. -- nosy: +rhettinger ___ Python tracker

[issue44586] unittest requires __init__.py for test discovery

Karthikeyan Singaravelan added the comment: See also https://bugs.python.org/issue23882 -- nosy: +xtreak ___ Python tracker ___

[issue44586] unittest requires __init__.py for test discovery

New submission from ma19 : This is how my project is currently set up: src: - main.py - src1.py - src2.py test: - __init__.py - test_src1.py - test_src2.py If I remove __init__.py from the "test" directory, the unittest discovery fails. I thought that __init__.py was

[issue43941] Unit test failure in test_gdb only with -O0

Skip Montanaro added the comment: Unfortunately, I'm currently not able to build Python 3.8, 3.9 or 3.10 and get a non-failing test_gdb. I'll mess around a bit more, but I'm skeptical I'll find something simple. (I wonder if something changed in GDB which is causing the failure.)

[issue43941] Unit test failure in test_gdb only with -O0

Pablo Galindo Salgado added the comment: Skip: I am still unable to reproduce in my machine unfortunately. Could you maybe bisect the failures if you can reliably reproduce the problem so we can at least narrow it down to one commit? -- ___

[issue43941] Unit test failure in test_gdb only with -O0

ched. Note that I have been getting CRC mismatches between a couple files. They are copious in the test output, so I won't elaborate here. -- nosy: +skip.montanaro Added file: https://bugs.python.org/file50140/test_gdb.out ___ Python tracker <https://bu

[issue44573] Organize some data files in the Lib/test directory

). I'm working on an organization so they don't get mixed up with the test files, but how the rest of the data files are organized (audiodata, capath, cjkencodings, etc.). -- components: Tests messages: 397056 nosy: Leonardofreua priority: normal severity: normal status: open title

[issue44515] contextlib test incompatibility with non-refcounted GC

Change by Nick Coghlan : -- keywords: +patch pull_requests: +25486 stage: commit review -> patch review pull_request: https://github.com/python/cpython/pull/26910 ___ Python tracker

[issue44515] contextlib test incompatibility with non-refcounted GC

Change by Nick Coghlan : -- versions: +Python 3.10, Python 3.11 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44515] contextlib test incompatibility with non-refcounted GC

New submission from Nick Coghlan : Backporting the latest contextlib module and test suite to contextlib2, I ran into a couple of CI failures on PyPy3. Investigation showed that a couple of the new test cases were assuming the use of a refcounted GC. One could be fixed by switching to using

[issue43553] [sqlite3] Improve test coverage

Change by Erlend E. Aasland : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue43553] [sqlite3] Improve test coverage

Pablo Galindo Salgado added the comment: New changeset 2c1ae09764446beda5248759fb99c859e14f1b25 by Erlend Egeberg Aasland in branch 'main': bpo-43553: Improve `sqlite3` test coverage (GH-26886) https://github.com/python/cpython/commit/2c1ae09764446beda5248759fb99c859e14f1b25

[issue44502] bla in cpython/Lib/test/test_sys_settrace.py

Irit Katriel added the comment: y = 1, so the body of the while loop will never execute and the name will never need to be resolved. The bug tracker is not an appropriate place to ask questions about the code, it is for reporting bugs in python. -- nosy: +iritkatriel resolution:

[issue44502] bla in cpython/Lib/test/test_sys_settrace.py

New submission from zcpara : In cpython/Lib/test/test_sys_settrace.py, there is a function: 1 def no_pop_blocks(): 2y = 1 3while not y: 4bla 5x = 1 what does bla mean? bla is not defined anywhere. But the function can pass the compilation. bla is treated as a global name

[issue43553] [sqlite3] Improve test coverage

Change by Erlend E. Aasland : -- pull_requests: +25464 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26886 ___ Python tracker ___

[issue14322] More test coverage for hmac

Change by Emmanuel Arias : -- nosy: +eamanu ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12600] Add example of using load_tests to parameterise Test Cases

Irit Katriel added the comment: It remains to update the load_test doc along the lines of Michael's suggestion in msg140999. -- keywords: +easy nosy: +iritkatriel versions: +Python 3.11 -Python 2.7, Python 3.2, Python 3.3 ___ Python tracker

[issue29153] Test test.test_asynchat.TestAsynchat / test.test_asynchat.TestAsynchat_WithPoll fail test_close_when_done

Irit Katriel added the comment: asynchat is deprecated since version 3.6 so there won't be any more development related to it. -- nosy: +iritkatriel resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker

[issue14322] More test coverage for hmac

Arjun added the comment: would the update invalid test belong in the TestVectorsTestCase class or should I make a new one? -- ___ Python tracker <https://bugs.python.org/issue14

[issue14322] More test coverage for hmac

Change by Arjun : -- pull_requests: +25222 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/26636 ___ Python tracker ___

[issue14322] More test coverage for hmac

Arjun added the comment: The only things I think we should add to the current hmac tests are test_update_error_handling and test_with_invalid_msg. For test_withnoncallable_digestmod(), hmac itself seems it can no longer be used: >>> hmac.HMAC(b"", None, "hmac") using new Traceback

<    4   5   6   7   8   9   10   11   12   13   >