[Grok-dev] Re: Iterativly emptying a grok.container shows weird behavior

[Philipp von Weitershausen]

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.

> Resume:
> 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 
> container.
> * FAILS iterativly DELETING all elements from a Container via the .keys().
> then the CAVEMAN will get very FRUSTRATED! ME ANGRY!! ME SMASH GROK! 
> SMASH!!!

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 
two-digit number.

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 
> newby.

Yes, but I don't think this counts as a violation of that principle.


-- 
http://worldcookery.com -- Professional Zope documentation and training