[issue27009] multiprocessing Connection data length limited to max(int32)
New submission from Hartmann: I wonder if size restriction for the data blobs send via multiprocessing.Connection is intentionally. Otherwise it would be nice to get rid of that restriction. File "python3.5/multiprocessing/connection.py", line 393, in _send_bytes header = struct.pack("!i", n) -- messages: 265396 nosy: cimatosa priority: normal severity: normal status: open title: multiprocessing Connection data length limited to max(int32) type: behavior versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue27009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27009] multiprocessing Connection data length limited to max(int32)
Changes by Hartmann : -- versions: +Python 3.5 -Python 3.6 ___ Python tracker <http://bugs.python.org/issue27009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15119] ctypes mixed-types bitfield layout nonsensical; doesn't match compiler.
Olaf Hartmann added the comment: I just run into this issue, so i'll bump it with another test case: import ctypes class Struct(ctypes.Structure): _fields_ = [ ("uint8_0", ctypes.c_uint8, 8), ("uint8_1", ctypes.c_uint8, 8), ("uint16_0", ctypes.c_uint16, 1), ("uint16_1", ctypes.c_uint16, 15), ] for f in Struct._fields_: print f[0], getattr(Struct, f[0]) > python bitfield.py uint8_0 uint8_1 uint16_0 uint16_1 Originally tested with Python 2.7.3, but also confirmed with later versions. Is there any workaround by specifying ofs and bits manually? -- nosy: +wbu versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue15119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15119] ctypes mixed-types bitfield layout nonsensical; doesn't match compiler.
Olaf Hartmann added the comment: Answering my own question, here is a workaround, that also produces reasonable results for the original test case. Basically just inserting an empty struct: import ctypes class Empty(ctypes.Structure): _fields_ = [] class Struct(ctypes.Structure): _fields_ = [ ("uint8_0", ctypes.c_uint8, 8), ("uint8_1", ctypes.c_uint8, 8), ("_ignore", Empty), ("uint16_0", ctypes.c_uint16, 1), ("uint16_1", ctypes.c_uint16, 15), ] for f in Struct._fields_: print f[0], getattr(Struct, f[0]) > python bitfield.py uint8_0 uint8_1 _ignore uint16_0 uint16_1 -- ___ Python tracker <http://bugs.python.org/issue15119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22989] HTTPResponse.msg not as documented
New submission from Paul Hartmann: HTTPResponse.msg is documented as a http.client.HTTPMessage object containing the headers of the response [1]. But in fact this is a string containing the status code: >>> import urllib.request >>> req=urllib.request.urlopen('http://heise.de') >>> content = req.read() >>> type(req.msg) >>> req.msg 'OK' This value is apparently overriden in urllib/request.py: ./urllib/request.py:1246:# This line replaces the .msg attribute of the HTTPResponse ./urllib/request.py-1247-# with .headers, because urllib clients expect the response to ./urllib/request.py:1248:# have the reason in .msg. It would be good to mark this ./urllib/request.py-1249-# attribute is deprecated and get then to use info() or ./urllib/request.py-1250-# .headers. ./urllib/request.py:1251:r.msg = r.reason Anyhow, it should be documented, that is not safe to retrieve the headers with HTTPResponse.msg and maybe add HTTPResponse.headers to the documentation. [1] https://docs.python.org/3/library/http.client.html -- assignee: docs@python components: Documentation messages: 232083 nosy: bastik, docs@python priority: normal severity: normal status: open title: HTTPResponse.msg not as documented versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue22989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com