On Mon, Jan 8, 2018 at 7:27 PM, Amit Green wrote:
> An argument against this API, is that any caller of recv should be doing
> error handling (i.e.: catching exceptions from the socket).
>
It's still not entirely clear, but I'm pretty sure this thread is talking
about multiprocessing.Connection
On Mon, Jan 8, 2018 at 10:34 PM, Nick Coghlan wrote
> It could be useful to include a recipe in the documentation that shows a
> generator with suitable error handling (taking the generic connection
> errors and adapting them to app specific ones) while also showing how to
> adapt the connection
On 9 January 2018 at 13:27, Amit Green wrote:
> An argument against this API, is that any caller of recv should be doing
> error handling (i.e.: catching exceptions from the socket).
>
> Changing into an iterator makes it less likely that error handling will be
> properly coded, and makes the err
An argument against this API, is that any caller of recv should be doing
error handling (i.e.: catching exceptions from the socket).
Changing into an iterator makes it less likely that error handling will be
properly coded, and makes the error handling more obscure.
Thus although the API would ma
The arguments for including this API is that it allows easy iteration over
the results of a connection allowing it to be used with any of the features
of itertools or any other library accepting iterables. recv is only used in
places where the iterable protocol could be used, so it makes sense for
On Mon, Jan 08, 2018 at 10:17:30AM -0600, Oscar Smith wrote:
> I am currently working on a program where it would be really useful if a
> connection had a __next__ method, because then it would be much easier to
> iterate over.
What sort of connection are you referring to?
> It would just be an
On 1/8/2018 11:17 AM, Oscar Smith wrote:
I am currently working on a program where it would be really useful if a
connection had a __next__ method, because then it would be much easier
to iterate over. It would just be an alias to recv, but would allow you
> to do things like merging the resul
I am currently working on a program where it would be really useful if a
connection had a __next__ method, because then it would be much easier to
iterate over. It would just be an alias to recv, but would allow you to do
things like merging the results of connections using heapq.merge that
current
