[Grok-dev] Re: Iterativly emptying a grok.container shows weird
Philipp von Weitershausen
philipp at weitershausen.de
Tue Jun 12 11:05:36 EDT 2007
Dr. Volker Jaenisch wrote:
> class Sample(grok.Application, grok.Container):
> def emptyContainer( self ):
> keys = 
> for key in self._SampleContainer__data.keys():
> keys.append( key )
> for key in keys :
> print key.__class__
> del self._SampleContainer__data[ key ]
You could've simply done
keys = list(container.keys())
to obtain an actual list and a permanent copy of the keys in the
container. Then mutating the container won't mutate that list.
> If you explain a CAVEMAN in the tutorial he may access a
> grok.container the way he would use a python dict and
> * learns he can ADD items as to a dict with  notation.
> * learns he can ADDRESS items as from a dict with  notation.
> * learns he can GET .keys() as from a dict.
> * learns he may ITERATE over the .keys() to ACCESS the items in the
> * FAILS iterativly DELETING all elements from a Container via the .keys().
> then the CAVEMAN will get very FRUSTRATED! ME ANGRY!! ME SMASH GROK!
To our defence, we nowhere say that containers *are*
> I am sure that someone will now point me to a ZODB-API-Function
> that will empty such a container flawlessly.
As Tres pointed out, mappings have a clear() method.
> I do not write this posting in search of such a function.
> As a CAVEMAN (addressed by GROK) myself also likes to have a container
> that behaves not 80% like a python dict, but 100%.
If it were simply possible to use a dict, we wouldn't have to use those
funky BTrees. Actually, it *is* possible to persist dicts, but it's
vastly inefficient once the number of contained items exceeds a
BTrees are very efficient when you have tons of things in a container.
Also, the size of those things doesn't matter at all if you just want to
get a keys() listing. For a detailed discussion of persistency with the
ZODB and storing mappings with BTrees, please refer to chapter 6 of my
Zope book (http://worldcookery.com).
> I talked to lots of other CAVEMAN/CAVEWOMEN in Potsdam that are more
> afraid of Zope3 than of the monolitic monster Zope2. The most heard
> question at the conference (implicitly raised by the first keynote)
> was "Should I use Zope3(GROK) or stay by Zope2 or change to Turbo-Gears
> or whatever?"
> We should build a Zope3 or GROK that is truly intuitivly usable by the
Yes, but I don't think this counts as a violation of that principle.
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev