[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)
Flavio Grossi added the comment: > About the new optional balanced parameter added downstream to Fedora, the > patch is very small compared to timedlock.patch. It only changes the Python > code, not the C code The balancing fix has 3 main problems imo: - It causes long delays to receive the notification (i.e. with a timeout of 30s the caller may be notified after 30s in the worst case) - It doesn't apply to other affected APIs, e.g. Queue.get() which uses a condition internally. - It only fixes the problem in python programs which explicitly use it (and being redhat specific i guess it is not very used) -- ___ Python tracker <http://bugs.python.org/issue25084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)
Flavio Grossi added the comment: >> however, being stuck to python 2.7 because of libraries > Are there private libraries or public libraries? It is a mix of public and internal libraries with the main public blockers being twisted and apache thrift (and other libs which have py3 alternatives but don't have retrocompatible apis). (Yes, twisted is almost supported, but still has some parts not ready for python 3) -- ___ Python tracker <http://bugs.python.org/issue25084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)
Flavio Grossi added the comment: First of all, thank you for your support. I fully understand what you are saying, however, being stuck to python 2.7 because of libraries still not ported to 3, this is a serious problem to us, and, while i agree this would introduce a new "feature", it also fixes a bug which in some cases renders some functionalities (Queue.get() for example) not very usable as it is. Is there any chance this will be fixed? Or even having the remaining thread implementations fixed will lead to reject this? Thank you -- ___ Python tracker <http://bugs.python.org/issue25084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)
New submission from Flavio Grossi: threading.Condition.wait(timeout=x) is implemented in python 2 as a semi-busy loop which causes cpu wakeups and unexpected cpu use. I think this is somewhat problematic since it causes problems in all modules which use that method, such as Queue.get() when used with a timeout. This issue has been reported and "fixed" in red hat based distributions in a way which i find problematic, as detailed here: https://bugzilla.redhat.com/show_bug.cgi?id=1230802 The attached patch backports the following change from py3 to fix the problem: https://hg.python.org/cpython/rev/01d1fd775d16/ -- components: Library (Lib) files: timedlock.patch keywords: patch messages: 250562 nosy: flavio, pitrou priority: normal severity: normal status: open title: remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file40450/timedlock.patch ___ Python tracker <http://bugs.python.org/issue25084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22666] email.Header no encoding of unicode strings containing newlines
Flavio Grossi added the comment:
Hi, and thank you for your answer.
However this is not strictly related to the newline, but also to some small
idiosyncrasies and different behavior among py2 and py3 (and even in py2 using
Header() or Charset()):
# py2.7, non-unicode str
>>> H('test', 'utf-8').encode()
'=?utf-8?q?test?='
>>> Charset('utf-8').header_encode('test')
'=?utf-8?q?test?='
# py2.7, unicode str
>>> H(u'test', 'utf-8').encode() # this is the only different result
'test'
>>> Charset('utf-8').header_encode(u'test')
u'=?utf-8?q?test?='
# py3.4, unicode
>>> H('test', 'utf-8').encode()
'=?utf-8?q?test?='
# py3.4, bytes
>>> H(b'test', 'utf-8').encode()
'=?utf-8?q?test?='
As you can see, the only when using unicode strings in py2.7 no header encoding
is done if the unicode string contains only ascii chars.
--
___
Python tracker
<http://bugs.python.org/issue22666>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22666] email.Header no encoding of unicode strings containing newlines
Flavio Grossi added the comment: any news? -- ___ Python tracker <http://bugs.python.org/issue22666> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22666] email.Header no encoding of unicode strings containing newlines
New submission from Flavio Grossi:
When trying to encode an email header with a newline in it, correct encoding is
done only for strings and not for unicode strings.
In fact, for unicode strings, encoding is only done if a non ascii character is
contained in it.
The attached patch should fix the problem.
Simple example to reproduce the problem:
>>> from email.Header import Header as H
# correctly encoded
>>> H('two\r\nlines', 'utf-8').encode()
'=?utf-8?q?two=0D=0Alines?='
# unicode string not encoded
>>> H(u'two\r\nlines', 'utf-8').encode()
'two\r\nlines'
# unicode string with non ascii chars, correctly encoded
>>> H(u'two\r\nlines and \xe0', 'utf-8').encode()
'=?utf-8?b?dHdvDQpsaW5lcyBhbmQgw6A=?='
--
components: email
files: fix_email_header_encoding_uses_ascii_before_selected_charset.diff
keywords: patch
messages: 229640
nosy: barry, flavio, r.david.murray
priority: normal
severity: normal
status: open
title: email.Header no encoding of unicode strings containing newlines
type: behavior
versions: Python 2.7
Added file:
http://bugs.python.org/file36959/fix_email_header_encoding_uses_ascii_before_selected_charset.diff
___
Python tracker
<http://bugs.python.org/issue22666>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
