On Tue, Jul 26, 2011 at 1:47 PM, Stephen J. Turnbull wrote:
> Eh, doesn't it bother anybody that it's not an error, but a user
> action?
Nope, doesn't bother me in the slightest. It's an error number code,
just like all the others. Several other error numbers may or may not
be errors too, dependi
Glenn Linderman writes:
> Sorry, no. "InterruptError" sounds too much like a CPU interrupt
> signal, which the error is not. "InterruptedError" is OK by me, I don't
> see the confusion you do. But maybe "InterruptedOperationError" would
> be the most clear. Way too long, of course, so m
Andrew Bennetts wrote:
Ethan Furman wrote:
[…] or "EINTRError" in my order of preference.
>>
Please not that last one! ;)
Why not, exactly?
Because this is Python, and readability counts. Yes, it does take some
getting used to (I finally stopped typing 'enum' a couple months ago ;)
, b
On Tue, Jul 26, 2011 at 10:26 AM, Andrew Bennetts wrote:
> When EINTR happens it's frequently a surprise, but programmers new to
> the concept can always search the web for advice on what causes it and
> how to deal with it (and after several attempts at dealing with it they
> may even get it righ
Ethan Furman wrote:
> > […] or "EINTRError" in my order of preference.
>
> Please not that last one! ;)
Why not, exactly?
When EINTR happens it's frequently a surprise, but programmers new to
the concept can always search the web for advice on what causes it and
how to deal with it (and after s
On Tue, Jul 26, 2011 at 4:44 AM, Ethan Furman wrote:
> Glenn Linderman wrote:
>>
>> On 7/25/2011 3:43 AM, Antoine Pitrou wrote:
>>> Ok, let's call it InterruptError then. InterruptedError sounds like the
>>> error was interrupted ;)
>>>
>>
>> Sorry, no. "InterruptError" sounds too much like a CP
On Sat, Jul 23, 2011 at 20:35, Eli Bendersky wrote:
> Some background: I'm working (on and off) on issue 11015 - documenting
> the public functions in test.support
>
> Some of the functions in test.support (for example unlink, rmtree)
> simply shadow existing & popular stdlib functions, with the
Glenn Linderman wrote:
On 7/25/2011 3:43 AM, Antoine Pitrou wrote:
On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlan wrote:
>
> > If we add EINTR, I don't know if it's better to add it to
> > BlockingIOError or to create a new exception (InterruptError?).
>
> InterruptedError seems like a re
On 25/07/2011 02:24, Antoine Pitrou wrote:
Hello,
By the way, is it faster to not handle and than re-raise unwanted
exceptions?
You mean "is it faster to not handle than re-raise unwanted
exceptions?". It probably is, yes.
I asked if:
try:
...
except FileNotFound:
pass
is faster than
On 7/25/2011 3:43 AM, Antoine Pitrou wrote:
On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlan wrote:
>
> > If we add EINTR, I don't know if it's better to add it to
> > BlockingIOError or to create a new exception (InterruptError?).
>
> InterruptedError seems like a reasonable candidate
On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlan wrote:
>
> > If we add EINTR, I don't know if it's better to add it to
> > BlockingIOError or to create a new exception (InterruptError?).
>
> InterruptedError seems like a reasonable candidate for addition to me
> - catch and retry in that case is
11 matches
Mail list logo
