Ethan Furman 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")
>>
>>
>
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 --
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 3
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 t
"Rob Richardson" 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
> processing of all
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
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:
Paul Rubin writes:
> Steven D'Aprano 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'
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/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". A
John Nagle 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". Applications should
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
On 12/6/2010 2:24 PM, Mark Wooding wrote:
John Nagle 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 i
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 t
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 g
John Nagle 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 StopIteration exc
Steven D'Aprano 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 empty iterable")
> p
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:
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 beca
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.
>>
>> http://mail.python.org/pipermail
On Fri, 03 Dec 2010 10:15:58 -0800, Paul Rubin wrote:
> Steven D'Aprano writes:
>> def func(iterable):
>> it = iter(iterable)
>> failed = False
>> try:
>> x = next(it)
>> except StopIteration:
>> failed = True
>> if failed:
>> raise ValueError("can't pr
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.
http://mail.python.org/pipermail/python-list/2010-October/1258606.
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 idea
Steven D'Aprano 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)
Untested:
from itertoo
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.ht
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
> http://mail.python.org/piperm
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 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)
Not exactly what you're look
On Oct 29, 8:53 am, rantingrick 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 and then doing
On 10/24/2010 5:36 AM, Steve Holden wrote:
On 10/24/2010 2:22 AM, Lawrence D'Oliveiro wrote:
In message, 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 conf
In message , 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"
)
--
http://mail.python.org/mailman/listinfo/python-list
Chris Rebert wrote:
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
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.
Yes, I can see that what S
MRAB wrote:
On 29/10/2010 11:24, Chris Rebert wrote:
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
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
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 s
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 except
On 29/10/2010 11:24, Chris Rebert wrote:
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
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
On Oct 24, 7:36 am, Steve Holden 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 completely misleading!
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
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 very
>> much apprec
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 abo
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 on
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 info
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/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
In message , 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
> the debugger of the consumed code).
Who needs t
Steve Holden 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 class of the exc
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.
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 the
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/24/2010 2:22 AM, Lawrence D'Oliveiro wrote:
> In message , 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 handli
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 handl
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
>>> > fi
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
In message , 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).
So what exactly is the problem? Exceptio
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]
>> > What
>> > i
On Sat, Oct 23, 2010 at 10:01 PM, 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).
> Give the traceback
55 matches
Mail list logo
