[issue47246] Race condition in `threadig.Thread._wait_for_tstate_lock`
Dieter Maurer added the comment: The observation was caused by a bug which has been fixed in newer Python versions (3.9+ if I remember correctly). `isAlive` was called on a `_DummyThread` (while `_DummyThread` overides `is_alive` it had forgotten to override `isAlive` as well). -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47246] Race condition in `threadig.Thread._wait_for_tstate_lock`
Dieter Maurer added the comment: Apparently, the explanation is not that easy: `_stop` first sets `_is_stopped` to `True` and only then `_tstate_lock` to `None`. Therefore, the race should not cause the `AssertionError`. I observed the `AssertionError` in Python 3.6. The related `threading` code is however almost identical to that in Python 3.11. -- ___ Python tracker <https://bugs.python.org/issue47246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47246] Race condition in `threadig.Thread._wait_for_tstate_lock`
New submission from Dieter Maurer : I have observed an `AssertionError (assert self._is_stopped)` in `threading.Thread._wait_for_tstate_lock`. This indicates that Python's internal state has been corrupted. The analysis revealed the following race condition: `_wait_for_tstate:lock` contains the code: ``` lock.release() self._stop() ``` The `lock.release()` allows a conflicting call to execute. If this happens before `self._stop()` has executed `self._is_stopped = True`, the `AssertionError` is raised. I suggest to give `_stop` an additional parameter `locked` with default `False`. In indicates whether the caller holds the `tstate_lock`. If this is the case, `_stop` releases the lock after it has ensured a consistent state (esspecially set `_is_stopped` to `True`). With this modification to `_stop` the two lines above can be replaced by `self._stop(locked=True)`. -- components: Library (Lib) messages: 416919 nosy: dmaurer priority: normal severity: normal status: open title: Race condition in `threadig.Thread._wait_for_tstate_lock` type: behavior versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue47246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36674] "unittest.TestCase.debug" should honour "skip" (and other test controls)
Dieter Maurer added the comment: Thank you for working on this issue! -- ___ Python tracker <https://bugs.python.org/issue36674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42549] "quopri" line endings not standard conform
New submission from Dieter Maurer : RFC 1521 and "https://tools.ietf.org/html/rfc2045#section-6.7"; stipulate that the quoted printable encoding uses CRLF line endings. Python's "quopri" implementation does not honor this. -- components: Library (Lib) messages: 382354 nosy: dmaurer priority: normal severity: normal status: open title: "quopri" line endings not standard conform type: behavior ___ Python tracker <https://bugs.python.org/issue42549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41307] "email.message.Message.as_bytes": fails to correctly handle "charset"
Dieter Maurer added the comment: The following fixes the example: from copy import copy from io import BytesIO from email.message import Message from email.generator import BytesGenerator, _has_surrogates from email._policybase import Compat32 class FixedBytesGenerator(BytesGenerator): def _handle_text(self, msg): payload = msg._payload if payload is None: return charset = msg.get_param("charset") if charset is not None \ and not self.policy.cte_type=='7bit' \ and not _has_surrogates(payload): msg = copy(msg) msg._payload = payload.encode(charset).decode( "ascii", "surrogateescape") super()._handle_text(msg) _writeBody = _handle_text class FixedMessage(Message): def as_bytes(self, unixfrom=False, policy=None): policy = self.policy if policy is None else policy fp = BytesIO() g = FixedBytesGenerator(fp, mangle_from_=False, policy=policy) g.flatten(self, unixfrom=unixfrom) return fp.getvalue() fixed_policy = Compat32(message_factory=FixedMessage) ms = message_from_string(mt, policy=fixed_policy) ms.as_bytes() -- ___ Python tracker <https://bugs.python.org/issue41307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41307] "email.message.Message.as_bytes": fails to correctly handle "charset"
New submission from Dieter Maurer : In the transscript below, "ms" and "mb" should be equivalent: >>> from email import message_from_string, message_from_bytes >>> mt = """\ ... Mime-Version: 1.0 ... Content-Type: text/plain; charset=UTF-8 ... Content-Transfer-Encoding: 8bit ... ... รค ... """ >>> ms = message_from_string(mt) >>> mb = message_from_bytes(mt.encode("UTF-8")) But "mb.as_bytes" succeeds while "ms.as_bytes" raises a "UnicodeEncodeError": >>> mb.as_bytes() b'Mime-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit\n\n\xc3\xa4\n' >>> ms.as_bytes() Traceback (most recent call last): ... File "/usr/local/lib/python3.9/email/generator.py", line 155, in _write_lines self.write(line) File "/usr/local/lib/python3.9/email/generator.py", line 406, in write self._fp.write(s.encode('ascii', 'surrogateescape')) UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 0: ordinal not in range(128) Apparently, the "as_bytes" ignores the "charset" parameter from the "Content-Type" header (it should use "utf-8", not "ascii" for the encoding). -- components: email messages: 373711 nosy: barry, dmaurer, r.david.murray priority: normal severity: normal status: open title: "email.message.Message.as_bytes": fails to correctly handle "charset" type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue41307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36674] "unittest.TestCase.debug" should honour "skip" (and other test controls)
Dieter Maurer added the comment: Terry J. Reedy wrote: > SkipTest is an exception and according to the doc it should be propagated to > the caller. __unittest_skip__ is an undocumented internal name, so you > probably should not be using it. > > If this request is not rejected, we will need test code demonstrating the > issue *that does not use zope*. The "skip" I am speaking about is a decorator for tests or test classes telling a "runner" to skip tests (likely because conditions for their success are not met - usually, that required packages are not installed). This "skip" (decorator) uses `__unittest_skip__` to tell the the "unittest runner" (that is `unittest.TestCase.run`) that the test should be skipped. The "unittest runner" is extremely rudimentary and lacks many important features. That is why I use the much more feature rich `zope.testrunner`. I could implement the `__unittest_skip__` logic there - but as you wrote - this should remain encapsulated inside `unittest` (that's why I wrote this issue). I attach a test script - which likely is not convincing as the feature is mainly important for a sophisticated test runner, not for explicit calls of `TestCase.debug`. -- Added file: https://bugs.python.org/file48287/utest.py ___ Python tracker <https://bugs.python.org/issue36674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36674] "unittest.TestCase.debug" should honour "skip" (and other test controls)
New submission from Dieter Maurer : Currently, "TestCase.run" supports several features to control testing - among others, a test can be skipped via the attribute "__unittest_skip__". "TestCase.debug" ignores all those controls and calls the test method unconditionally. I am using "zope.testrunner" to run test suites. Its "-D" option switches from "TestCase.run" to "TestCase.debug" in order to allow the analysis of the state of a failing test in the Python debugger. "-D" is typically used if a test in a larger suite failed and a detailed analysis is required to determine the failure's cause. It is important that this second run executes the same tests as the first run; it is not helpful when the second run fails in a test skipped in the first run. Therefore, "TestCase.debug" should honour all test controls supported by "TestCase.run". One could argue that the testsuite runner should implement this logic. However, this would force the runner to duplicate the test control logic using internal implementation details of "unittest". Conceptually, it is much nicer to have the test control encapsulated by "unittest". -- components: Library (Lib) messages: 340569 nosy: dmaurer priority: normal severity: normal status: open title: "unittest.TestCase.debug" should honour "skip" (and other test controls) type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue36674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36554] unittest.TestCase: "subTest" cannot be used together with "debug"
Dieter Maurer added the comment: This is a duplicate of issue34900 -- stage: -> resolved status: open -> closed Added file: https://bugs.python.org/file48249/utest.py ___ Python tracker <https://bugs.python.org/issue36554> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36554] unittest.TestCase: "subTest" cannot be used together with "debug"
Change by Dieter Maurer : Added file: https://bugs.python.org/file48248/utest.py ___ Python tracker <https://bugs.python.org/issue36554> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36554] unittest.TestCase: "subTest" cannot be used together with "debug"
New submission from Dieter Maurer : "subTest" accesses "self._outcome" which is "None" when the test is performed via "debug". -- components: Library (Lib) messages: 339607 nosy: dmaurer priority: normal severity: normal status: open title: unittest.TestCase: "subTest" cannot be used together with "debug" type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue36554> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35283] "threading._DummyThread" redefines "is_alive" but forgets "isAlive"
Dieter Maurer added the comment: > Hi, I am going to solve this issue through below process. > ... > Is it okay? For me, this would be perfect. -- ___ Python tracker <https://bugs.python.org/issue35283> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35283] "threading._DummyThread" redefines "is_alive" but forgets "isAlive"
Dieter Maurer added the comment: > Care to open a PR to fix this? I am not familiar with the "github" workflow. The fix is so trivial (add the "isAlive = is_alive" alias to "threading._DummyThread" and replace "isAlive" by "is_alive" in the docstring of "threading.Thread.join" that it does not seem worth to learn the "github" workflow just for this fix. -- ___ Python tracker <https://bugs.python.org/issue35283> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35283] "threading._DummyThread" redefines "is_alive" but forgets "isAlive"
New submission from Dieter Maurer : In module "threading", class "Thread" defines "is_alive" and defines "isAlive = is_alive". The derived class "_DummyThread" redefines "is_alive" but forgets to update the "isAlive" alias. As a consequence, calling "_DummyThread.isAlive" leads to an "AssertionErrror". The "isAlive" method is mentioned in the docstring of "Thread.join". -- components: Library (Lib) messages: 330158 nosy: dmaurer priority: normal severity: normal status: open title: "threading._DummyThread" redefines "is_alive" but forgets "isAlive" type: crash ___ Python tracker <https://bugs.python.org/issue35283> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2767] "doctest.DocTestCase.debug" clears "test.globs" too early
New submission from Dieter Maurer <[EMAIL PROTECTED]>: "doctest.DocTestCase.debug" calls "DebugRunner.run" without "clear_globs=False". As a consequence, already the runner clears "test.globs" and it is no longer available to "tearDown" (where is it cleared again). -- components: Library (Lib) messages: 66262 nosy: dmaurer severity: normal status: open title: "doctest.DocTestCase.debug" clears "test.globs" too early type: behavior versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2767> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2766] Doubtfull code in 'doctest.DocTestSuite'
New submission from Dieter Maurer <[EMAIL PROTECTED]>: "doctest.DocTestSuite" has parameter "globs=None". It uses "globs" in the call to "test_finder.call". After this use, it potentually modifies "globs" but no longer uses it. Either the "globs" modification is irrelevant (then it should be removed) or it should happen before the "test_finder.find" call. -- components: Library (Lib) messages: 66259 nosy: dmaurer severity: normal status: open title: Doubtfull code in 'doctest.DocTestSuite' versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2766> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1785] "inspect" gets broken by some descriptors
Dieter Maurer added the comment: In "dm.zdoc" (a "pydoc" wrapper for Zope) I simply filter out all names returned by "dir" which cannot be "getattr"ed. But, I am not sure, that this is good enough to be accepted as a patch (although it already improves upon the current state) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1785> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1785] "inspect" gets broken by some descriptors
New submission from Dieter Maurer: The inspect functions "getmembers(cls)" and "classify_class_attrs(cls)" require that for a class *cls* each name in "dir(cls)" can be retrieved by "getattr(cls, name)". While this holds for usual class attributes, it may well fail for descriptors (descriptors set by 'zope.interface' are a real world example for this). Attached it as small script that demonstrates the problem. The bug affects 'pydoc' and the built in 'help' (which is in fact 'pydoc.help'). While 'pydoc' and 'help' do not break completely, they can not present meaningful information for classes with some descriptors -- components: Library (Lib) files: inspectBug.py messages: 59675 nosy: dmaurer severity: normal status: open title: "inspect" gets broken by some descriptors type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9117/inspectBug.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1785> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com