«

Quoth Michele Simionato:
> [...] In other words I am looking for an
> "isempty" function to use in "if" statements such as
>
> if isempty(iterator):
> do_something()
>
> without side effects. [...]

I don't have anything substantial to add to others' posts, but I
wonder: under what circumstances do you want to do this?

--
Steven Taschuk 7\ 7'Z {&~ .
Y r --/hG-
(__/ )_ 1^1`

Michele Simionato wrote:
> I wanted to check the output of ifilter or imap; at the end I solved
> my problem in another way, nevertheless I am surprised there is no
> way to check for an empty iterator in current Python, it seems to be
> a quite legitimate question, isn't it?

It would make writing iterators more difficult because you'd have to know
that there is a first element before the first call to .next ().

It shouldn't be too difficult to write an iterator wrapper class that does
exactly what you want (not tested):

class IteratorWrapper:
def __init__ (self, iterArg):
iterArg = iter (iterArg)
try:
self.firstElement = iterArg.next ()
self.isEmpty = false
self.next = self.returnFirstElement
self.baseIter = iterArg
except StopIteration:
self.isEmpty = true
self.next = self.throwStopIteration

def returnFirstElement (self):
self.next = self.baseIter.next
return self.firstElement

def throwStopIteration (self):
throw StopIteration

Daniel

"Michele Simionato" <> wrote in message
news: om...
> I wanted to check the output of ifilter or imap; at the end I solved
> my problem in another way, nevertheless I am surprised there is no
> way to check for an empty iterator in current Python, it seems to be
> a quite legitimate question, isn't it?

As I understand, the iterator protocol was primarily designed to be
the *minimum* necessary to work (behind the scene) in

for item in iterable:
<statements>

statements, replacing and improving upon the getitem interface (kept
only for use by old code and likely to disappear in 3.0 ). It works
quite well for this designed purpose. In this context one usually
does not even have a handle on the iterator and thereor no means of
calling a precheck method.

Iterators were secondarily intended for the equivalent

iterator = iter(iterable)
try:
while 1:
item = iterator.next()
<statements>
except StopIteration: pass

Here the iterator is visibly bound, but the basic idea of 'process
each item' is the same. In any case, it is the stark simplicity of
the protocol that makes possible the current version of generators and
the neat trick of transfering the function body to the .next method.

One who wants to add more to the interface should, I think, expect to
add code somewhere to make the added function come true.

Terry J. Reedy

Quoth Michele Simionato:
> Steven Taschuk <> wrote in message news:<mailman.1058835583.22488.python->...
[...]
> > I don't have anything substantial to add to others' posts, but I
> > wonder: under what circumstances do you want to do this?
>
> I wanted to check the output of ifilter or imap; [...]

Ah. And then, if there were elements in the iterator, I assume
you would then process them somehow, right? Why not just do that
with a for loop, say, and check afterwards whether anything has
been done? A silly example:

processed = 0
for x in iterator:
process(x)
processed = processed + 1
if processed:
# ...

> [...] at the end I solved
> my problem in another way, nevertheless I am surprised there is no
> way to check for an empty iterator in current Python, it seems to be
> a quite legitimate question, isn't it?

Absolutely. I was just curious what the original problem was.

(I haven't read the iterators PEP in a while, but it seems to me
the iterator protocol is deliberately minimalistic. Makes it
easier to write them; and if you do frequently need lookahead,
writing a wrapper as others have suggested seems easy enough.)

--
Steven Taschuk "The world will end if you get this wrong."
-- "Typesetting Mathematics -- User's Guide",
Brian Kernighan and Lorrinda Cherry

On Tue, 22 Jul 2003 16:41:29 -0600, Steven Taschuk <> wrote:

>Quoth Michele Simionato:
>> Steven Taschuk <> wrote in message news:<mailman.1058835583.22488.python->...
> [...]
>> > I don't have anything substantial to add to others' posts, but I
>> > wonder: under what circumstances do you want to do this?
>>
>> I wanted to check the output of ifilter or imap; [...]
>
>Ah. And then, if there were elements in the iterator, I assume
>you would then process them somehow, right? Why not just do that
>with a for loop, say, and check afterwards whether anything has
>been done? A silly example:
>
> processed = 0
> for x in iterator:
> process(x)
> processed = processed + 1
> if processed:
> # ...
>
You can avoid flag bumping in the loop:

>>> x = object(); idx=id(x)
>>> for x in iter(''): print x,
...
>>> id(x)==idx
1
>>> for x in iter('abcd'): print x,
...
a b c d
>>> id(x)==idx
0

Regards,
Bengt Richter

Daniel Dittmar wrote:

> It shouldn't be too difficult to write an iterator wrapper class
> that does exactly what you want (not tested):
>
> class IteratorWrapper:
> def __init__ (self, iterArg):
> iterArg = iter (iterArg)
> try:
> self.firstElement = iterArg.next ()
> self.isEmpty = false
> self.next = self.returnFirstElement
> self.baseIter = iterArg
> except StopIteration:
> self.isEmpty = true
> self.next = self.throwStopIteration
>
> def returnFirstElement (self):
> self.next = self.baseIter.next
> return self.firstElement
>
> def throwStopIteration (self):
> throw StopIteration
^^^^^

Ahem, cough, I think, em, maybe you mean "raise"?

That java stuff polluting your mind, eh?

As an aside, I've got to hand it to Java for exception handling. Java
was the language that taught me how to do proper and robust exception
handling, by "rapping my knuckles" continually, and actually making me
think about the exception hierarchies I was generating and processing.
You can't just randomly define and generate new exceptions: you have
to change your method definition to declare that it can throw the new
exception. Which means you either have to handle the exception in the
calling method, or change *that* method signature to permit
re-throwing of the exception, and so on up the hierarchy.

It's not very pythonic though.

regards,

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan