On Tue, 27 Aug 2013 00:00:36 -0500, Skip Montanaro wrote:
I found this question/answer on Stack Overflow:
http://stackoverflow.com/questions/15123137
but after fiddling around with it, I can't find a solution that works
for Python 3.2 and 3.3, let alone 2.x. In 3.2, exceptions have both
()
Traceback (most recent call last):
File stdin, line 1, in module
File lockfile/pidlockfile.py, line 94, in acquire
raise LockFailed(failed to create %s % self.path)
LockFailed: failed to create /tmp/skip/lock
It appears exception handling changed in Python 3. How do I suppress
the lower
exception handling changed in Python 3. How do I suppress
the lower level OSError?
Do this:
raise LockFailed(Failed to create %s % self.path) from None
--
http://mail.python.org/mailman/listinfo/python-list
Do this:
raise LockFailed(Failed to create %s % self.path) from None
Thanks. Is there some construct which will work in 2.x and 3.x?
Skip
--
http://mail.python.org/mailman/listinfo/python-list
On 08/26/2013 07:49 PM, Skip Montanaro wrote:
Do this:
raise LockFailed(Failed to create %s % self.path) from None
Thanks. Is there some construct which will work in 2.x and 3.x?
Something like this (untested):
exc = None
try:
write_pid_to_lockfile(somefile)
except
I found this question/answer on Stack Overflow:
http://stackoverflow.com/questions/15123137
but after fiddling around with it, I can't find a solution that works
for Python 3.2 and 3.3, let alone 2.x. In 3.2, exceptions have both
__cause__ and __context__ attributes. I tried setting both to
Paul Rubin no.em...@nospam.invalid writes:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
Apart from this horrible idiom:
def func(iterable):
it = iter(iterable)
failed = False
try:
x = next(it)
except StopIteration:
failed = True
if
Arnaud,
Wouldn't your first suggestion exit after the first element in iterable?
And would your second suggestion throw an exception after normal
processing of all elements in the interator?
RobR
-Original Message-
I missed the start of this discussion but there are two simpler ways:
Please don't top-post.
Rob Richardson wrote:
-Original Message-
I missed the start of this discussion but there are two simpler ways:
def func(iterable):
for x in iterable:
print(x)
return
raise ValueError(... empty iterable)
Or using 3.x's next's optional
Rob Richardson rob.richard...@rad-con.com writes:
You shouldn't top-post!
Arnaud,
Wouldn't your first suggestion exit after the first element in iterable?
Yes, after printing that element, which is what the code I quoted did.
And would your second suggestion throw an exception after normal
Arnaud Delobelle wrote:
I missed the start of this discussion but there are two simpler ways:
def func(iterable):
for x in iterable:
print(x)
return
raise ValueError(... empty iterable)
For the immediate case this is a cool solution.
Unfortunately, it doesn't fix
Ethan Furman wrote:
Please don't top-post.
Rob Richardson wrote:
-Original Message-
I missed the start of this discussion but there are two simpler ways:
def func(iterable):
for x in iterable:
print(x)
return
raise ValueError(... empty iterable)
Or using
Ethan Furman wrote:
Arnaud Delobelle wrote:
I missed the start of this discussion but there are two simpler ways:
def func(iterable):
for x in iterable:
print(x)
return
raise ValueError(... empty iterable)
For the immediate case this is a cool solution.
Drat -- I
Ethan Furman et...@stoneleaf.us writes:
Ethan Furman wrote:
Arnaud Delobelle wrote:
I missed the start of this discussion but there are two simpler ways:
def func(iterable):
for x in iterable:
print(x)
return
raise ValueError(... empty iterable)
For the
John Nagle na...@animats.com writes:
PEP 255, like too much Python literature, doesn't distinguish
clearly between the language definition and implementation detail. It
says The mechanics of StopIteration are low-level details, much like
the mechanics of IndexError in Python 2.1.
On 12/7/2010 5:58 AM, John Nagle wrote:
PEP 255, like too much Python literature, doesn't distinguish clearly
between the language definition and implementation detail. It says
The mechanics of StopIteration are low-level details, much like the
mechanics of IndexError in Python 2.1.
On 12/7/2010 1:48 AM, MRAB wrote:
Perhaps Python could use Guido's time machine to check whether the
sequence will yield another object in the future. :-)
Since there's only one time machine that would effectively be a lock
across all Python interpreters.
regards
Steve
--
Steve Holden
On 12/3/2010 5:04 AM, Steven D'Aprano wrote:
Consider the following common exception handling idiom:
def func(iterable):
it = iter(iterable)
try:
x = next(it)
except StopIteration:
raise ValueError(can't process empty iterable)
print(x)
The intention is:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
Apart from this horrible idiom:
def func(iterable):
it = iter(iterable)
failed = False
try:
x = next(it)
except StopIteration:
failed = True
if failed:
raise ValueError(can't process
John Nagle na...@animats.com writes:
Right. You're not entitled to assume that StopIteration is how a
generator exits. That's a CPyton thing; generators were a retrofit,
and that's how they were hacked in. Other implementations may do
generators differently.
This is simply wrong. The
On Mon, 06 Dec 2010 13:13:40 -0800, Paul Rubin wrote:
It's really unfortunate, though, that Python 3 didn't offer a way to
peek at the next element of an iterable and test emptiness directly.
This idea of peekable iterables just won't die, despite the obvious flaws
in the idea.
There's no
On 07/12/2010 00:23, Steven D'Aprano wrote:
On Mon, 06 Dec 2010 13:13:40 -0800, Paul Rubin wrote:
It's really unfortunate, though, that Python 3 didn't offer a way to
peek at the next element of an iterable and test emptiness directly.
This idea of peekable iterables just won't die, despite
On 12/6/2010 2:24 PM, Mark Wooding wrote:
John Naglena...@animats.com writes:
Right. You're not entitled to assume that StopIteration is how a
generator exits. That's a CPyton thing; generators were a retrofit,
and that's how they were hacked in. Other implementations may do
generators
On 12/6/2010 4:23 PM, Steven D'Aprano wrote:
On Mon, 06 Dec 2010 13:13:40 -0800, Paul Rubin wrote:
It's really unfortunate, though, that Python 3 didn't offer a way to
peek at the next element of an iterable and test emptiness directly.
This idea of peekable iterables just won't die, despite
Consider the following common exception handling idiom:
def func(iterable):
it = iter(iterable)
try:
x = next(it)
except StopIteration:
raise ValueError(can't process empty iterable)
print(x)
The intention is:
* detect an empty iterator by catching StopIteration;
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
Consider the following common exception handling idiom:
def func(iterable):
it = iter(iterable)
try:
x = next(it)
except StopIteration:
raise ValueError(can't process empty iterable)
print(x)
Steven D'Aprano wrote:
Consider the following common exception handling idiom:
def func(iterable):
it = iter(iterable)
try:
x = next(it)
except StopIteration:
raise ValueError(can't process empty iterable)
print(x)
The intention is:
* detect an
Peter Otten __pete...@web.de writes:
Note that StopIteration is an internal detail of no relevance whatsoever
to the caller. Expose this is unnecessary at best and confusing at worst.
http://mail.python.org/pipermail/python-list/2010-October/1258606.html
Hrvoje Niksic wrote:
Peter Otten __pete...@web.de writes:
Note that StopIteration is an internal detail of no relevance whatsoever
to the caller. Expose this is unnecessary at best and confusing at
worst.
http://mail.python.org/pipermail/python-list/2010-October/1258606.html
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
def func(iterable):
it = iter(iterable)
failed = False
try:
x = next(it)
except StopIteration:
failed = True
if failed:
raise ValueError(can't process empty iterable)
print(x)
Peter Otten wrote:
http://mail.python.org/pipermail/python-list/2010-October/1258606.html
http://mail.python.org/pipermail/python-list/2010-October/1259024.html
I found #6210 on bugs.python.org -- does anyone know if there are any
others regarding this issue? Or any progress on MRAB's
Peter Otten wrote:
Hrvoje Niksic wrote:
Peter Otten __pete...@web.de writes:
Note that StopIteration is an internal detail of no relevance whatsoever
to the caller. Expose this is unnecessary at best and confusing at
worst.
On Fri, 03 Dec 2010 10:15:58 -0800, Paul Rubin wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
def func(iterable):
it = iter(iterable)
failed = False
try:
x = next(it)
except StopIteration:
failed = True
if failed:
raise
On Fri, 03 Dec 2010 16:26:19 +0100, Hrvoje Niksic wrote:
Peter Otten __pete...@web.de writes:
Note that StopIteration is an internal detail of no relevance
whatsoever to the caller. Expose this is unnecessary at best and
confusing at worst.
On Fri, 03 Dec 2010 17:08:38 +0100, Peter Otten wrote:
After rereading the original post I still don't get why the workarounds
provided in those links aren't worth considering.
The first work-around:
http://mail.python.org/pipermail/python-list/2010-October/1258606.html
is unsuitable
On Oct 29, 8:53 am, rantingrick rantingr...@gmail.com wrote:
I am the programmer, and when i say to my interpretor show this
exception instead of that exception i expect my interpretor to do
exactly as i say or risk total annihilation!! I don't want my
interpreter interpreting my intentions
On 10/24/2010 5:36 AM, Steve Holden wrote:
On 10/24/2010 2:22 AM, Lawrence D'Oliveiro wrote:
In messagemailman.176.1287896531.2218.python-l...@python.org, Steve
Holden wrote:
Yes, *if the exception is caught* then it doesn't make any difference.
If the exception creates a traceback, however,
In message mailman.372.1288353590.2218.python-l...@python.org, Antoine
Pitrou wrote:
If you want to present exceptions to users in a different way ...
sys.stderr.write \
(
Traceback (most recent call last):\n
...
AttributeError: blah blah blah ...\n
)
--
Steve Holden wrote:
Yeah, that's a given. Ruby would probably let you do that, but Python
insists that you don't dick around with the built-in types. And roghtly
so, IMHO.
Some restrictions on this are necessary -- it obviously
wouldn't be safe to allow replacing the class of an
object with
Chris Rebert wrote:
Your Traceback is merely being made slightly longer/more
complicated than you'd prefer; however, conversely, what if a bug was
to be introduced into your exception handler? Then you'd likely very
much appreciate the superfluous Traceback info.
I think what's disturbing
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
Chris Rebert wrote:
Your Traceback is merely being made slightly longer/more
complicated than you'd prefer; however, conversely, what if a bug was
to be introduced into your exception handler? Then you'd likely
On Oct 24, 7:36 am, Steve Holden st...@holdenweb.com wrote:
I don't want people to think this is a big deal, however.
Nonsense, this IS a big deal. (and Steve grow a spine already!) I was
not even aware of this issue until you brought it up -- although i
will admit your choice of title is
On 29/10/2010 11:24, Chris Rebert wrote:
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
Chris Rebert wrote:
Your Traceback is merely being made slightly longer/more
complicated than you'd prefer; however, conversely, what if a bug was
to be introduced into
On 24/10/2010 13:28, Steve Holden wrote:
On 10/24/2010 4:48 AM, Martin v. Loewis wrote:
Am 24.10.2010 07:01, schrieb Steve Holden:
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it reports it
as a separate
MRAB wrote:
On 24/10/2010 13:28, Steve Holden wrote:
On 10/24/2010 4:48 AM, Martin v. Loewis wrote:
Am 24.10.2010 07:01, schrieb Steve Holden:
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it
reports it
as a
MRAB wrote:
On 29/10/2010 11:24, Chris Rebert wrote:
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
Chris Rebert wrote:
Your Traceback is merely being made slightly longer/more
complicated than you'd prefer; however, conversely, what if a bug was
to be
Chris Rebert wrote:
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
I think what's disturbing about this is that the two halves of
the extended traceback are printed in the wrong order. We're
True, but swapping the order would only worsen Steve's problem.
Am 24.10.2010 23:48, schrieb Steve Holden:
On 10/24/2010 4:44 PM, John Nagle wrote:
Are exception semantics changing in a way which would affect that?
No, I don't believe so. I simply felt that the traceback gives too much
information in the case where an exception is specifically being
On 10/25/2010 2:57 AM, Martin v. Loewis wrote:
Am 24.10.2010 23:48, schrieb Steve Holden:
On 10/24/2010 4:44 PM, John Nagle wrote:
Are exception semantics changing in a way which would affect
that?
No, I don't believe so. I simply felt that the traceback gives too
much information in the
In message mailman.176.1287896531.2218.python-l...@python.org, Steve
Holden wrote:
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it reports it
as a separate exception that occurred during the handling of the
Am 24.10.2010 07:01, schrieb Steve Holden:
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it reports it
as a separate exception that occurred during the handling of the first).
I think you are misinterpreting
Steve Holden wrote:
On 10/24/2010 1:26 AM, Chris Rebert wrote:
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it reports
it as a separate exception that occurred during the handling of the
first).
snip
On 10/24/2010 4:48 AM, Martin v. Loewis wrote:
Am 24.10.2010 07:01, schrieb Steve Holden:
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it reports it
as a separate exception that occurred during the handling of
On 10/24/2010 2:22 AM, Lawrence D'Oliveiro wrote:
In message mailman.176.1287896531.2218.python-l...@python.org, Steve
Holden wrote:
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it reports it
as a separate
On 10/24/10 16:01, Steve Holden wrote:
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it reports it
as a separate exception that occurred during the handling of the first).
FYI, Java has a similar behavior. In
On 10/23/2010 10:42 PM, Steve Holden wrote:
On 10/24/2010 1:26 AM, Chris Rebert wrote:
I was somewhat surprised to discover that Python 3 no longer
allows an
exception to be raised in an except clause (or rather that it
reports it as a separate exception that occurred during the
handling of
On 10/24/2010 4:44 PM, John Nagle wrote:
Are exception semantics changing in a way which would affect that?
No, I don't believe so. I simply felt that the traceback gives too much
information in the case where an exception is specifically being raised
to replace the one currently being handled.
Steve Holden st...@holdenweb.com writes:
I simply felt that the traceback gives too much information in the
case where an exception is specifically being raised to replace the
one currently being handled.
Ideally, that description of the problem would suggest the obvious
solution: replace the
In message mailman.190.1287924006.2218.python-l...@python.org, Steve
Holden wrote:
Yes, *if the exception is caught* then it doesn't make any difference.
If the exception creates a traceback, however, I maintain that the
additional information is confusing to the consumer (while helpful to
On 10/24/2010 7:51 PM, Ben Finney wrote:
which means, AFAICT, that re-binding ‘__class__’ is only allowed for
objects of a type defined in the Python run-time heap, not those defined
in C code (like the built-in-exception types).
Yeah, that's a given. Ruby would probably let you do that, but
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it reports it
as a separate exception that occurred during the handling of the first).
So the following code:
d = {}
try:
... val = d['nosuch']
... except:
...
On Sat, Oct 23, 2010 at 10:01 PM, Steve Holden st...@holdenweb.com wrote:
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it reports it
as a separate exception that occurred during the handling of the first).
snip
On 10/24/2010 1:26 AM, Chris Rebert wrote:
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it reports it
as a separate exception that occurred during the handling of the first).
snip
[snip]
What
is the
63 matches
Mail list logo
