[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/python/2.7/lib/python2.7/threading.py", line 505, in run
self.__target(*self.__args, **self.__kwargs)
File "/opt/python/2.7/lib/python2.7/multiprocessing/pool.py", line 347, in
_handle_results
task = get()
TypeError: ('__init__() takes at least 3 arguments (1 given)', , ())
--
nosy: +Daniel.Blanchard
versions: +Python 2.7 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue9400>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 accepted. -- ___ Python tracker <http://bugs.python.org/issue9400> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue9998> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 and UTF-32 encodings.
For example:
>>> 'foo'.encode('utf-16le')
b'f\x00o\x00o\x00'
>>> 'foo'.encode('utf-16')
b'\xff\xfef\x00o\x00o\x00'
You can see that when using UTF-16 (instead of UTF-16LE), you get the BOM
correctly prepended to the bytes.
If you were on a little endian system and purposefully wanted to create a
UTF-16BE file, the only way to do it is:
>>> codecs.BOM_UTF16_BE + 'foo'.encode('utf-16be')
b'\xfe\xff\x00f\x00o\x00o'
This doesn't make a lot of sense to me. Why is the BOM not prepended
automatically when encoding with UTF-16BE?
Furthermore, if you were given a UTF-16BE file on a little endian system, you
might think that this would be the correct way to decode it:
>>> (codecs.BOM_UTF16_BE + 'foo'.encode('utf-16be')).decode('utf-16be')
'\ufefffoo'
but as you can see that leaves the BOM on there. Strangely, decoding with
UTF-16 works fine however:
>>> (codecs.BOM_UTF16_BE + 'foo'.encode('utf-16be')).decode('utf-16')
'foo'
It seems to me that the endian-specific versions of UTF-16 and UTF-32 should be
adding/removing the appropriate BOMs, and this is a long-standing bug.
--
components: Unicode
messages: 252406
nosy: Daniel.Blanchard, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: UTF-16LE, UTF-16BE, UTF-32LE, and UTF-32BE encodings don't add/remove
BOM on encode/decode
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue25325>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, > UTF-16LE, UTF-32BE or UTF-32LE, a BOM is neither necessary nor permitted. Any > U+FEFF would be interpreted as a ZWNBSP. Anyway, the thing that brought this up is that in chardet we detect codecs of files for people and we've been returning UTF-16BE or UTF-16LE when we detect the BOM at the front of the file, but we recently learned that if people tried to decode with those codecs things don't work as expected. It seems the correct behavior in our case is to just return UTF-16 in these cases. -- ___ Python tracker <http://bugs.python.org/issue25325> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
