An iteration idiom (Was: Re: [Guppy-pe-list] loading files containing multiple dumps)
Chris Withers
chris at simplistix.co.uk
Thu Sep 3 05:05:25 EDT 2009
Raymond Hettinger wrote:
> In the first case, you would write:
> sets.extend(h.load(f))
yes, what I had was:
for s in iter(h.load(f)): sets.append(s)
...which I mistakenly thought was working, but in in fact boils down to
Raymond's code.
The problem is that each item that h.load(f) returns *is* actually an
iterable, so either of the above just ends up the contents of each set
being extended onto `sets` rather than the sets themselved.
It's all really rather confusing, apologies if there's interspersed rant
in here:
>>> from guppy import hpy
>>> h = hpy()
Minor rant, why do I have to instantiate a
<class 'guppy.heapy.Use._GLUECLAMP_'>
to do anything with heapy?
Why doesn't heapy just expose load, dump, etc?
(oh, and reading the code for guppy.heapy.Use and its ilk made me go
temporarily blind!) ;-)
>>> f = open('copy.hpy')
>>> s = h.load(f)
Less minor rant: this applies to most things to do with heapy... Having
__repr__ return the same as __str__ and having that be a long lump of
text is rather annoying. If you really must, make __str__ return the big
lump of text but have __repr__ return a simple, short, item containing
the class, the id, and maybe the number of contained objects...
Anyway...
>>> id(s)
13905272
>>> len(s)
192
>>> s.__class__
<class guppy.heapy.Part.Stat at 0x00CD6A20>
>>> i = s[0]
>>> id(i)
13904112
>>> len(i)
1
>>> i.__class__
<class guppy.heapy.Part.Stat at 0x00CD6A20>
Hmmm, I'm sure there's a good reason why an item in a set has the exact
same class and iterface as a whole set?
It feels like some kind of filtering, where are the docs that explain
all this?
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
More information about the Python-list
mailing list