[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
[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
[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
[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
[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 getattred. 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
