Irmen de Jong added the comment:
Sure, I'll give it another go.
I've not done any c-development for quite a while though, so I have to pick up
the pieces and see how far I can get. Also, I don't have any compiler for
Windows so maybe I'll need someone else to validate
Irmen de Jong added the comment:
Ok I've looked at it again and think I can build an acceptable patch this time.
However there are 2 things that I'm not sure of:
1) how to return the partial data to the application if the recv() loop fails
before completion. Because the method wil
Irmen de Jong added the comment:
Ok I think I've got the code and doc changes ready. I added a recvall and a
recvall_into method to the socket module. Any partially received data in case
of errors is returned to the application as part of the args for a new
exception, socket.partialdata
Changes by Irmen de Jong :
Removed file: http://bugs.python.org/file6439/patch.txt
___
Python tracker
<http://bugs.python.org/issue1103213>
___
___
Python-bugs-list mailin
Changes by Irmen de Jong :
Added file: http://bugs.python.org/file16762/socketmodulepatch.txt
___
Python tracker
<http://bugs.python.org/issue1103213>
___
___
Python-bug
Changes by Irmen de Jong :
Added file: http://bugs.python.org/file16763/libpatch.txt
___
Python tracker
<http://bugs.python.org/issue1103213>
___
___
Python-bugs-list m
Changes by Irmen de Jong :
Added file: http://bugs.python.org/file16764/docpatch.txt
___
Python tracker
<http://bugs.python.org/issue1103213>
___
___
Python-bugs-list m
Irmen de Jong added the comment:
Currently if MSG_WAITALL is defined, recvall() just calls recv() internally
with the extra flag. Maybe that isn't the smartest thing to do because it
duplicates recv's behavior on errors. Which is: release the data and raise an
error.
Would it b
New submission from Irmen de Jong :
Doc/library/socket.rst doesn't mention the return value for recv_into. Adding a
simple "Returns the number of bytes received." should fix this.
(note that recvfrom_into does mention its return value)
--
assignee: georg.br
New submission from Irmen de Jong :
Pickling of bytearrays is quite inefficient right now, because bytearray's
__reduce__ encodes the bytes of the bytearray into a str. A pickle made from a
bytearray is quite a bit larger than necessary because of this, and it also
takes a lot more proce
Changes by Irmen de Jong :
Added file: http://bugs.python.org/file23813/bytearray27.patch
___
Python tracker
<http://bugs.python.org/issue13503>
___
___
Python-bugs-list m
Irmen de Jong added the comment:
btw I'm aware of PEP-3154 but I don't think this particular patch requires a
pickle protocol bump.
--
___
Python tracker
<http://bugs.python.o
Irmen de Jong added the comment:
Added new patch that only does the new reduction when protocol is 3 or higher.
--
Added file: http://bugs.python.org/file23852/bytearray3x_reduceex.patch
___
Python tracker
<http://bugs.python.org/issue13
Irmen de Jong added the comment:
Alexandre: the existing test_bytes already performs byte array pickle tests.
--
___
Python tracker
<http://bugs.python.org/issue13
New submission from Irmen de Jong <[EMAIL PROTECTED]>:
I've ran into a problem where it would be very nice to be able to tell
the tread.get_ident() of a given threading.Thread object.
Currently, when creating a new Thread object, there is no good way of
getting that thread's g
Irmen de Jong <[EMAIL PROTECTED]> added the comment:
Adding it in the run method would only work for threads that I create in
my own code. The thing is: I need to be able to get the tread
identification from threads created by third party code. So I cannot
rely on that code putting it
Irmen de Jong <[EMAIL PROTECTED]> added the comment:
Thanks Gregory, for taking the time to make a patch.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2871>
__
17 matches
Mail list logo
