I assume that ESHUTDOWN is the errno in question? (This is also already
mentioned in the PEP.)
Indeed, I mentioned it in the PEP, as it appears in asyncore.py.
But I can't find it on www.opengroup.org, and no man page on my Linux
system (except the errno man page) seems to mention it.
2011/7/27 Charles-François Natali neolo...@free.fr:
I assume that ESHUTDOWN is the errno in question? (This is also already
mentioned in the PEP.)
Indeed, I mentioned it in the PEP, as it appears in asyncore.py.
But I can't find it on www.opengroup.org, and no man page on my Linux
system
On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlan ncogh...@gmail.com wrote:
There may be some error codes that we choose to map to these generic
errors, even if we don't give them their own exception types at this
point (e.g. ECONSHUTDOWN could map directly to ConnectionError).
Ok, I can find
On Jul 26, 2011, at 6:49 PM, Antoine Pitrou wrote:
On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlan ncogh...@gmail.com wrote:
There may be some error codes that we choose to map to these generic
errors, even if we don't give them their own exception types at this
point (e.g. ECONSHUTDOWN
On Tue, 26 Jul 2011 19:32:56 -0400
Glyph Lefkowitz gl...@twistedmatrix.com wrote:
On Jul 26, 2011, at 6:49 PM, Antoine Pitrou wrote:
On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlan ncogh...@gmail.com wrote:
There may be some error codes that we choose to map to these generic
errors,
On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlan ncogh...@gmail.com 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
On 7/25/2011 3:43 AM, Antoine Pitrou wrote:
On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlanncogh...@gmail.com 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
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:
Glenn Linderman wrote:
On 7/25/2011 3:43 AM, Antoine Pitrou wrote:
On Mon, 25 Jul 2011 15:28:47 +1000
Nick Coghlan ncogh...@gmail.com 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
On Tue, Jul 26, 2011 at 4:44 AM, Ethan Furman et...@stoneleaf.us 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 CPU
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
On Tue, Jul 26, 2011 at 10:26 AM, Andrew Bennetts and...@bemusement.org 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
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 ;)
, but
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 maybe
On Tue, Jul 26, 2011 at 1:47 PM, Stephen J. Turnbull step...@xemacs.org 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
Arguments in favor of specific errors
-
Using specific errors avoids the need of import errno. The import is
sometimes done in the except block, which may raise a new error (and may
be slow).
I like specific exceptions because it avoids the need of re-raise
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 don't understand how Antoine decided which errno should have an
exception or not.
Mostly experience with the
Antoine Pitrou writes:
Did someone test Blender, Django or another major applications on the
implementation of the PEP 3151?
Does Django have a working Python 3 port yet?
Define working. Martin ported Django to Python 3 years ago as proof
of concept, but never claimed it was ready
On Mon, Jul 25, 2011 at 9:56 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
By the way, is it faster to not handle and than re-raise unwanted
exceptions?
Yes, but probably not that much faster given the overhead of
instantiating the exception and unwinding the stack in the first
place.
19 matches
Mail list logo
