[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Daniel Blanchard added the comment: I believe I'm still encountering this issue in 2.7: Exception in thread Thread-3: Traceback (most recent call last): File "/opt/python/2.7/lib/python2.7/threading.py", line 552, in __bootstrap_inner self.run() File "/opt/pyth

[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions

Daniel Blanchard added the comment: The patch appears to fix the issue, so is there any chance of this actually getting accepted this time? It seems bizarre that such a simple bug that has been on the books for almost two years now can't get a patch acc

[issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux

Daniel Blanchard added the comment: Any chance of this making it into 3.4? This is a rather annoying deficiency of find_library(). -- nosy: +Daniel.Blanchard ___ Python tracker <http://bugs.python.org/issue9

[issue9998] ctypes find_library should search LD_LIBRARY_PATH on Linux

Changes by Daniel Blanchard : -- nosy: -Daniel.Blanchard ___ Python tracker <http://bugs.python.org/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25325] UTF-16LE, UTF-16BE, UTF-32LE, and UTF-32BE encodings don't add/remove BOM on encode/decode

New submission from Daniel Blanchard: As I recently discovered when someone filed a PR on chardet (see https://github.com/chardet/chardet/issues/70), BOMs are handled are not handled correctly by the endian-specific encodings UTF-16LE, UTF-16BE, UTF-32LE, and UTF-32BE, but are by the UTF-16

[issue25325] UTF-16LE, UTF-16BE, UTF-32LE, and UTF-32BE encodings don't add/remove BOM on encode/decode

Daniel Blanchard added the comment: Thanks for straightening me out there! I had not noticed this in the Unicode FAQ before: > Where the data has an associated type, such as a field in a database, a BOM > is unnecessary. In particular, if a text data stream is marked as UTF-16BE, >