An iteration idiom (Was: Re: [Guppy-pe-list] loading files containing multiple dumps)

Chris Withers chris at simplistix.co.uk
Thu Sep 3 11:05:25 CEST 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