I'm using using generators and iterators more and more intead of
passing lists around, and prefer them. However, I'm not clear on the
best way to detect an empty generator (one that will return no items)
when some sort of special case handling is required.
Typical code for handling an empty list:
if somelist:
for x in somelist:
something(x)
else:
empty_list_special_case
But this doesn't work with iterators -- a generator is "true"
regardless of whether its going to return any items. (I understand
why).
The closest equivalent I know of is:
n = 0
for n, x in enumerate(somegenerator()):
something(x)
if n == 0:
empty_list_special_case
Which seems rather awkward -- doesn't read as easily for me, and
introduces another variable.
Q1: Is there a better or alternate way to handle this?
Q2: Is there a way that handles both lists and generators, so I don't
have to worry about which one I've got?
Thanks,
Brian. 10 7734
Brian Roberts wrote: I'm using using generators and iterators more and more intead of passing lists around, and prefer them. However, I'm not clear on the best way to detect an empty generator (one that will return no items) when some sort of special case handling is required.
Usually it will be the job of the generator to signal something like
this. I think a possible way might be:
class GeneratorEmpty: pass
def generator():
if not X:
raise GeneratorEmpty
for i in X:
yield i
try:
for x in generator
something (x)
except GeneratorEmpty:
generator_special_case
The trick is that when generators raise exceptions they terminate.
Although this is probably not what you want. The thing is that you
cannot know if a generator will return any elements until you call
its next() method.
Q2: Is there a way that handles both lists and generators, so I don't have to worry about which one I've got?
I don't think this is possible. A generator must be called (with
next()) in order for its code to take over and see if it is empty or
not. Unlike the list.
jfj
In article <50*************************@posting.google.com> , br***@mirror.org (Brian Roberts) wrote: I'm using using generators and iterators more and more intead of passing lists around, and prefer them. However, I'm not clear on the best way to detect an empty generator (one that will return no items) when some sort of special case handling is required.
The best I can come up with is to depend on the fact that
for item in foo:
pass
only defines item if foo yields any items. Assuming item is not defined
before you execute the for loop, you can check to see if it's defined after
the loop, and use that to tell if foo was an empty list or generator.
Here's a demo. Unfortunately, I'm not sure if it's really any cleaner than
your way (but at least it doesn't add any extraneous variables)
# Creates an iterator which yields n items.
class gen:
def __init__(self, n):
self.n = n
def __iter__(self):
for i in range(self.n):
yield None
def checkEmpty(genOrList):
for item in genOrList:
pass
try:
item
print "%s had items" % genOrList
except NameError:
print "%s was empty" % genOrList
checkEmpty(gen(0))
checkEmpty(gen(1))
checkEmpty([])
checkEmpty([1])
--------------
Roy-Smiths-Computer:play$ ./gen.py
<__main__.gen instance at 0x36c620> was empty
<__main__.gen instance at 0x36c620> had items
[] was empty
[1] had items
On Mon, 02 May 2005 16:14:57 -0700, Brian Roberts wrote: Q1: Is there a better or alternate way to handle this? Q2: Is there a way that handles both lists and generators, so I don't have to worry about which one I've got?
Are you in control of your generators? You could put a method on them that
tells if there is anything in them by manually implementing the .next()
call.
The other thing you could do is a generator wrapper that can tell for you,
but you'll lose some performance:
class EmptyGeneratorDetector(object):
"""Provides a method you can call to detect an empty
generator. You should probably name this class something
shorter.
Check if the generator is empty after construction by looking at
the isEmpty property."""
def __init__(self, generator):
self.generator = generator
self.isEmpty = False
self.givenFirst = False
try:
self.firstItem = generator.next()
except StopIteration:
self.isEmpty = True
def next(self):
if self.isEmpty:
raise StopIteration
if not self.givenFirst:
self.givenFirst = True
return self.firstItem
else:
return self.generator.next()
def __iter__(self):
return self
In action:
Python 2.3.5 (#1, Mar 3 2005, 17:32:12)
[GCC 3.4.3 (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6)] on linux2
Type "help", "copyright", "credits" or "license" for more information. from genwrap import * def emptyGenerator():
.... raise StopIteration
.... yield None
.... def nonEmptyGenerator():
.... yield 1
.... yield 2
.... yield 3
.... e = emptyGenerator() n = nonEmptyGenerator() E = EmptyGeneratorDetector(e) N = EmptyGeneratorDetector(n) E.isEmpty
True N.isEmpty
False for i in E:
.... print i
.... for i in N:
.... print i
....
1
2
3
It is tested as much as you see it above :-)
(I recall a lengthy discussion of the best way to create an empty iterator
a while back, and that was not the winner. But it will do for now.)
On 2 May 2005 16:14:57 -0700, br***@mirror.org (Brian Roberts) wrote: I'm using using generators and iterators more and more intead of passing lists around, and prefer them. However, I'm not clear on the best way to detect an empty generator (one that will return no items) when some sort of special case handling is required.
Typical code for handling an empty list: if somelist: for x in somelist: something(x) else: empty_list_special_case
But this doesn't work with iterators -- a generator is "true" regardless of whether its going to return any items. (I understand why).
The closest equivalent I know of is: n = 0 for n, x in enumerate(somegenerator()): something(x) if n == 0: empty_list_special_case
Which seems rather awkward -- doesn't read as easily for me, and introduces another variable.
And, if I understood the intent, doesn't work ;-) n = 0 for n, x in enumerate(c for c in 'a'):
... print 'something', x
...
something a if n == 0:
... print 'empty list special case ??'
...
empty list special case ??
You could have used n = -1 as a sentinel that enumerate would not set,
but using a guaranteed-unique sentinel, you don't need enumerate, e.g.,
x = sentinel = object() for x in (c for c in 'a'):
... print 'something', x
...
something a if x is sentinel:
... print 'empty list special case ??'
...
(nothing printed there)
and for the actually empty sequence
x = sentinel = object() for x in (c for c in ''):
... print 'something', x
... if x is sentinel:
... print 'empty list special case ??'
...
empty list special case ?? Q1: Is there a better or alternate way to handle this? Q2: Is there a way that handles both lists and generators, so I don't have to worry about which one I've got?
UIAM this should work for any iterable. You don't have to manufacture
a locally bound sentinel as above. You could pick anything to preset
the for-target that you know is not going to be produced by the iterable,
though you might need to use '==' instead of 'is' depending on your choice.
But e.g., I don't think I'd write
x = Exception # weird sentinel choice
for x in mystring:
print x, ord(x)
if x is Exception:
print 'null sequence'
None probably works well a lot of the time, but not always.
Similarly ''. Seems like a builtin sentinel binding like sentinel = object()
might be handy to standardize usage.
Regards,
Bengt Richter
Starting from Python 2.4 we have tee in the itertools
module, so you can define the following:
from itertools import tee
def is_empty(it):
it_copy = tee(it)[1]
try:
it_copy.next()
except StopIteration:
return True
else:
return False
It works with generic iterables too.
Michele Simionato
"Brian Roberts" <br***@mirror.org> wrote in message
news:50*************************@posting.google.co m... I'm using using generators and iterators more and more intead of passing lists around, and prefer them. However, I'm not clear on the best way to detect an empty generator (one that will return no items) when some sort of special case handling is required.
If you write an iterator class instead of the abbreviated generator form,
and you can tell from the initialization parameters whether there will be
any data, then you can give the class a __nonzero__ method. You can also
have an initially nonempty iterator flag when it becomes empty.
My point is that writing an iterator as a generator is a convenience, not a
necessity, and that one gives up the full flexibility of an iterator class
when one does so, but that one is not required to do so.
I quite understanding wanting to have your cake and eat it too. The
convenience is sometimes major.
Terry J. Reedy
Jeremy Bowers wrote: def __init__(self, generator): self.generator = generator
You'll want to use iter(generator) there in order to handle reiterables.
On Wed, 04 May 2005 13:45:00 +0000, Leif K-Brooks wrote: Jeremy Bowers wrote: def __init__(self, generator): self.generator = generator
You'll want to use iter(generator) there in order to handle reiterables.
Can you expand that explanation a bit? I'm not certain what you mean. I'm
just trusting what the user passes in; maybe the user should pass it
iter(generator) when it's a "reiterable"? (Honest question.)
What definition of "re-iterable" are you using? (A quick google for
"Python reiterabile" just turns up some Python dev list entries from 2003.)
Jeremy Bowers wrote: On Wed, 04 May 2005 13:45:00 +0000, Leif K-Brooks wrote:
Jeremy Bowers wrote:
def __init__(self, generator): self.generator = generator
You'll want to use iter(generator) there in order to handle reiterables.
Can you expand that explanation a bit? I'm not certain what you mean. I'm just trusting what the user passes in; maybe the user should pass it iter(generator) when it's a "reiterable"? (Honest question.)
What definition of "re-iterable" are you using? (A quick google for "Python reiterabile" just turns up some Python dev list entries from 2003.)
Reiterable is generally defined as an object which can be iterated over
multiple times (i.e. is iterable but isn't an iterator). The simplest
example is a list, but a few other built-in types (set and dict, for
instance) also qualify.
With the EmptyGeneratorDetector class as you defined it, lists will fail: EmptyGeneratorDetector([])
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 15, in __init__
AttributeError: 'list' object has no attribute 'next'
Of course, the class is labeled as an empty generator detector, not an
empty iterable detector, so it's doing what it says it will, but a
little bit of extra generalism can't hurt.
On Wed, 04 May 2005 20:33:31 +0000, Leif K-Brooks wrote: With the EmptyGeneratorDetector class as you defined it, lists will fail:
>>> EmptyGeneratorDetector([])
Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 15, in __init__ AttributeError: 'list' object has no attribute 'next'
Of course, the class is labeled as an empty generator detector, not an empty iterable detector, so it's doing what it says it will, but a little bit of extra generalism can't hurt.
OK, thanks, now I see what you mean. I was worried that you might be
referring to an iterator type that returned something other than itself
when you called iter on it, which I thought wasn't legal. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Francis Avila |
last post by:
Below is an implementation a 'flattening' recursive generator (take a nested
iterator and remove all its nesting). Is this possibly general and useful
enough to be included in itertools? (I know...
|
by: Francis Avila |
last post by:
A little annoyed one day that I couldn't use the statefulness of
generators as "resumable functions", I came across Hettinger's PEP 288
(http://www.python.org/peps/pep-0288.html, still listed as...
|
by: Michael Sparks |
last post by:
Hi,
I'm posting a link to this since I hope it's of interest to people here :)
I've written up the talk I gave at ACCU Python UK on the Kamaelia Framework,
and it's been published as a BBC...
|
by: Lasse Vågsæther Karlsen |
last post by:
I need to merge several sources of values into one stream of values. All
of the sources are sorted already and I need to retrieve the values from
them all in sorted order.
In other words:
s1 = ...
|
by: Joachim Worringen |
last post by:
I need to process large lists (in my real application, this is to parse the
content of a file). I noticed that the performance to access the individual list
elements degrades over runtime.
This...
|
by: christophertidy |
last post by:
Hi
I am new to Python and have recieved this error message when trying to
instantiate an object from a class from another file within the same
directory and wondered what I have done wrong.
I...
|
by: Sun |
last post by:
Maybe this is a very primative question, but I just get a bit confused about
'set' and 'Set' module in python.
I understand 'set' is a build in type in python after 2.4(or 2.3) and Set a...
|
by: Martin Sand Christensen |
last post by:
Hi!
First a bit of context.
Yesterday I spent a lot of time debugging the following method in a
rather slim database abstraction layer we've developed:
,----
| def selectColumn(self,...
|
by: Yves Dorfsman |
last post by:
Is there a way to do:
x =
x
That would return:
I am surprised this notation is not supported, it seems intuitive.
A concrete example of the sort of thing I want to do:
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |