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
28 matches
Mail list logo
