[issue27009] multiprocessing Connection data length limited to max(int32)

2016-05-12 Thread Hartmann

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)

2016-05-12 Thread Hartmann

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.

2014-07-16 Thread Olaf Hartmann

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.

2014-07-16 Thread Olaf Hartmann

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

2014-12-03 Thread Paul Hartmann

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