By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,767 Members | 1,357 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,767 IT Pros & Developers. It's quick & easy.

__nonzero__ of iterators

P: n/a
Hi,

I just discovered the following pitfall in Python 2.3.
Consider the following code :
a = {}
bool (a.keys ()) False bool (a.iterkeys ())

True

So, an "empty" iterator evaluates to True in boolean context.
At a first glance, this is not what one would expect. This causes
several problems, e.g. if you operate on something expected to be
sequence, and you guard your code with "if seq :" to avoid crashing into
an empty sequence, you still crash if you get an empty iterator, even if
the rest of your code is able to deal with an iterator as well as with
any other sequence type.

At a second glance, the behaviour is clear, since the iterator object
does not know wheter it is able to provide the next element, before
having done so.

Anyway, although I don't know how the iterator protocol is implemented
in Python 2.3, I suppose the __nonzero__ could be changed to check
whether a next element can be provided without actually consuming it.

I would like to read some comments on this topic as I'm sure that I'm
not the first one wondering whether the current behaviour should be that
way.

thanks
chris

Jul 18 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Christian Eder wrote:
Hi,

I just discovered the following pitfall in Python 2.3.
Consider the following code :
>>> a = {}
>>> bool (a.keys ()) False >>> bool (a.iterkeys ())

True

So, an "empty" iterator evaluates to True in boolean context.
At a first glance, this is not what one would expect. This causes
several problems, e.g. if you operate on something expected to be
sequence, and you guard your code with "if seq :" to avoid crashing into
an empty sequence, you still crash if you get an empty iterator, even if
the rest of your code is able to deal with an iterator as well as with
any other sequence type.

At a second glance, the behaviour is clear, since the iterator object
does not know wheter it is able to provide the next element, before
having done so.

Anyway, although I don't know how the iterator protocol is implemented
in Python 2.3, I suppose the __nonzero__ could be changed to check
whether a next element can be provided without actually consuming it.

I would like to read some comments on this topic as I'm sure that I'm
not the first one wondering whether the current behaviour should be that
way.

thanks
chris


In fact, what is missing is a 'hasNext' function...

But for your example, the behavior is quite clear.
bool(a.keys()) == bool([]) == False
Whereas:
bool(a.iterkeys()) = bool(anIterator) == (anIterator != None) == True

So what is really missing is a hasNext method on Iterator. It would also
be usefull in some loop.

But what to do with Generator ?

Yermat

Jul 18 '05 #2

P: n/a

"Christian Eder" <ed**@tttech.com> wrote in message
news:c4**********@ttt14.vie.at.tttech.ttt...
Hi,

I just discovered the following pitfall in Python 2.3.
Consider the following code :
>>> a = {}
>>> bool (a.keys ()) False >>> bool (a.iterkeys ())
True

So, an "empty" iterator evaluates to True in boolean context.
At a first glance, this is not what one would expect. This causes
several problems, e.g. if you operate on something expected to be
sequence, and you guard your code with "if seq :" to avoid crashing into
an empty sequence, you still crash if you get an empty iterator, even if
the rest of your code is able to deal with an iterator as well as with
any other sequence type.

At a second glance, the behaviour is clear, since the iterator object
does not know wheter it is able to provide the next element, before
having done so.

Anyway, although I don't know how the iterator protocol is implemented
in Python 2.3, I suppose the __nonzero__ could be changed to check
whether a next element can be provided without actually consuming it.

I would like to read some comments on this topic as I'm sure that I'm
not the first one wondering whether the current behaviour should be that
way.


One of the issues is that the iterator many not be able, even in
principle, be able to figure out whether there is, in fact, a next
element. Consider a pipe or an internet connection.

However, you're talking about the special iterator that the
dictionary object returns. I'm not sure whether this behavior
is a bug or a feature. It would clearly be possible for that
iterator object to proxy the __nonzero__ call to the basic
dictionary object, and from what you show, it doesn't do so.

I belive this is a quite different issue from a "has next" type
of function.

John Roth
thanks
chris

Jul 18 '05 #3

P: n/a
Christian Eder <ed**@tttech.com> wrote in message news:<c4**********@ttt14.vie.at.tttech.ttt>...
<snip>
I would like to read some comments on this topic as I'm sure that I'm
not the first one wondering whether the current behaviour should be that
way.


Indeed. You may want to read this thread of last summer:

http://groups.google.it/groups?hl=it....lang.python.*

Michele Simionato
Jul 18 '05 #4

P: n/a
[Christian Eder]
I just discovered the following pitfall in Python 2.3.
Consider the following code :
>>> a = {}
>>> bool (a.keys ()) False >>> bool (a.iterkeys ()) True

So, an "empty" iterator evaluates to True in boolean context.
At a first glance, this is not what one would expect. This causes
several problems, e.g. if you operate on something expected to be
sequence, and you guard your code with "if seq :" to avoid crashing into
an empty sequence, you still crash if you get an empty iterator, even if
the rest of your code is able to deal with an iterator as well as with
any other sequence type.
This was fixed in Py2.4:

Python 2.4a0 (#46, Apr 4 2004, 05:21:08) [MSC v.1200 32 bit (Intel)]
on win32
IDLE 1.1a0
d = dict(a=1, b=2, c=3)
it = d.iterkeys()
bool(it) True list(it) ['a', 'c', 'b'] bool(it)

False

[John Roth] One of the issues is that the iterator many not be able, even in
principle, be able to figure out whether there is, in fact, a next
element. Consider a pipe or an internet connection.

However, you're talking about the special iterator that the
dictionary object returns. I'm not sure whether this behavior
is a bug or a feature. It would clearly be possible for that
iterator object to proxy the __nonzero__ call to the basic
dictionary object, and from what you show, it doesn't do so.

I belive this is a quite different issue from a "has next" type
of function.


Right. So, the only iterators that provide knowledge of their length
are the ones like dictionaries that know what lies ahead. For the
rest, the behavior is unchanged (i.e. they do not provide a __len__()
method).
Raymond Hettinger
Jul 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.