On Tue, 9 Jan 2018 08:39:06 -0800
Nathaniel Smith wrote:
> On Jan 9, 2018 04:12, "Random832" wrote:
>
> On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote:
> > If you view them as comparable to subprocess pipes, then it can be
> > surprising that they're not iterable when using a line-oriented
>
On 01/09/2018 08:27 AM, Chris Angelico wrote:
On Tue, Jan 9, 2018 at 11:12 PM, Random832 wrote:
On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote:
If you view them as comparable to subprocess pipes, then it can be
surprising that they're not iterable when using a line-oriented
protocol.
If yo
On Jan 9, 2018 04:12, "Random832" wrote:
On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote:
> If you view them as comparable to subprocess pipes, then it can be
> surprising that they're not iterable when using a line-oriented
> protocol.
>
> If you instead view them as comparable to socket conne
On Tue, Jan 9, 2018 at 11:12 PM, Random832 wrote:
> On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote:
>> If you view them as comparable to subprocess pipes, then it can be
>> surprising that they're not iterable when using a line-oriented
>> protocol.
>>
>> If you instead view them as comparable
09.01.18 12:46, Nick Coghlan пише:
On 9 January 2018 at 20:07, Antoine Pitrou wrote:
On Mon, 8 Jan 2018 21:22:56 -0800
Nathaniel Smith wrote:
I'm surprised that multiprocessing.Connection isn't iterable -- it seems
like an obvious oversight.
What is obvious about making a connection iterabl
On Tue, Jan 9, 2018, at 05:46, Nick Coghlan wrote:
> If you view them as comparable to subprocess pipes, then it can be
> surprising that they're not iterable when using a line-oriented
> protocol.
>
> If you instead view them as comparable to socket connections, then the
> lack of iteration suppo
On Tue, Jan 9, 2018 at 2:07 AM, Antoine Pitrou wrote:
> On Mon, 8 Jan 2018 21:22:56 -0800
> Nathaniel Smith wrote:
>>
>> The only documented error from multiprocessing.Connection.recv is EOFError,
>> which is basically equivalent to a StopIteration.
>
> Actually recv() can raise an OSError corres
On Tue, 9 Jan 2018 20:46:35 +1000
Nick Coghlan wrote:
> On 9 January 2018 at 20:07, Antoine Pitrou wrote:
> > On Mon, 8 Jan 2018 21:22:56 -0800
> > Nathaniel Smith wrote:
> >> I'm surprised that multiprocessing.Connection isn't iterable -- it seems
> >> like an obvious oversight.
> >
> > Wha
On 9 January 2018 at 20:07, Antoine Pitrou wrote:
> On Mon, 8 Jan 2018 21:22:56 -0800
> Nathaniel Smith wrote:
>> I'm surprised that multiprocessing.Connection isn't iterable -- it seems
>> like an obvious oversight.
>
> What is obvious about making a connection iterable? It's the first
> time I
On Mon, 8 Jan 2018 21:22:56 -0800
Nathaniel Smith wrote:
>
> The only documented error from multiprocessing.Connection.recv is EOFError,
> which is basically equivalent to a StopIteration.
Actually recv() can raise an OSError corresponding to any system-level
error.
> I'm surprised that multipr
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
17 matches
Mail list logo
