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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dr. Volker Jaenisch wrote:
> HI GROK ME VOLKER!
> 
> Hello Martijn. Saw your wonderful presentation in Potsdam last week.
> It encouraged me to do grokking. We are on to build
> a large community portal and we will definitivly use zope3/GROK.
> 
> ME LIKE CODING STYLE. ME LIKE COMPONENTS!
> 
> But after the first hour with GROK I run into some weird things.
> 
> Starting with your last tutorial example I modified the code to
> generate a lot of Entry-Instances (performance testing in mind).
> 
>     def update(self, name=None, text=None):
>         if name is None or text is None:
>           return
>         for n in range(10):
>             self.context[name + str(n)] = Entry(text + str(n) )
> 
> GROK RUN FAST! ME LIKE GROK!
> 
> Now to the weirdness:
> If I implement a routine to SMASH Entry-Instances from the container:
> 
>     def update(self, name=None, text=None, value=None):
>        """If empty text or name field delete all Entry instances"""
>         if name is None or text is None or text == '' or name == '':
>             for key in self.context.keys() :
>                 del self.context[ key ]
>             return
>         for n in range(10):
>             self.context[name + str(n)] = Entry(text + str(n) )
> 
> only every second entry is deleted. [Sorry for this ugly coding.]
> 
> 
>     Existing entries
> 
>     * e0 <http://10.3.0.45:8080/test1/e0>
>     * e1 <http://10.3.0.45:8080/test1/e1>
>     * e2 <http://10.3.0.45:8080/test1/e2>
>     * e3 <http://10.3.0.45:8080/test1/e3>
>     * e4 <http://10.3.0.45:8080/test1/e4>
>     * e5 <http://10.3.0.45:8080/test1/e5>
>     * e6 <http://10.3.0.45:8080/test1/e6>
>     * e7 <http://10.3.0.45:8080/test1/e7>
>     * e8 <http://10.3.0.45:8080/test1/e8>
>     * e9 <http://10.3.0.45:8080/test1/e9>
> 
> 
>     Add a new entry
> 
> Name: <empty>
> Text: <empty>
> 
>     * e1 <http://10.3.0.45:8080/test1/e1>
>     * e3 <http://10.3.0.45:8080/test1/e3>
>     * e5 <http://10.3.0.45:8080/test1/e5>
>     * e7 <http://10.3.0.45:8080/test1/e7>
>     * e9 <http://10.3.0.45:8080/test1/e9>
> 
> 
> ME VOLKER SAY SHIT! :-)
> 
> The reason for this behavior may be due to the fact that self 
> context.keys() is
> mapped to a OOBTreeItems instance instead of simply returning a list of 
> keys - as a dict would do.
> An OOBTreeItems seems to be an iterator/walker-like-class which operates 
> on low level keys.
> 
> ME VOLKER ASK BUG OR FEATURE? VOLKER NO LIKE BUG! VOLKER NO LIKE FEATURE!


Volker might like it more if the container had 100,000 items in it,
where iterating over the keys rather than getting them all back as a
list would be much faster.

> The problem is analogous to this one a (python) programming newby may 
> run into
> writing the following fragment of code:
> 
> alist = [1,2,3,4]
> 
> for i in range(3):
>   del alist[i]
> 
>  >>>range eror<<<
> 
> print alist
> [2, 4]

Mutating a container while iterating over it is always problematic.


> 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!!!
>
> I am sure that someone will now point me to a ZODB-API-Function
> that will empty such a container flawlessly.

Just to oblige:

 >>> from BTrees.OOBTree import OOBTree
 >>> dir(OOBTree)
 ['__class__', '__contains__', '__delattr__', '__delitem__', '__doc__',
  '__getattribute__', '__getitem__', '__getstate__', '__hash__',
  '__init__', '__iter__', '__len__', '__new__', '__nonzero__',
  '__reduce__', '__reduce_ex__', '__repr__', '__setattr__',
  '__setitem__', '__setstate__', '__str__', '_bucket_type', '_check',
  '_firstbucket', '_p_activate', '_p_changed', '_p_deactivate',
  '_p_delattr', '_p_getattr', '_p_invalidate', '_p_jar', '_p_mtime',
  '_p_oid', '_p_resolveConflict', '_p_serial', '_p_setattr', '_p_state',
  'byValue', 'clear', 'get', 'has_key', 'insert', 'items', 'iteritems',
  'iterkeys', 'itervalues', 'keys', 'maxKey', 'minKey', 'pop',
  'setdefault', 'update', 'values']

The 'clear' method is what you want.  Note that dict objects have a
'clear' method as well:

  >>> {}.clear
  <built-in method clear of dict object at 0x9681cec>

> 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%.
> 
> 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?"

I'm afraid I didn't convey my point, then:  using Zope3 (and Grok) to
build your application is a perfectly valid choice, and one which I
expect to remain attractive to many, especially those who don't need to
interoperate with existing Zope2 applications.  I was arguing that the
Zope "brand" isn't strong enough to carry two separate platrforms, and
that we can safely talk only about "Zope" while still using whichever
pieces of the current Zope2 or Zope3 platforms are suitable to our
applications.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbq0t+gerLs4ltQ4RAiWuAJ94wTQIhOK3+iL1MIioZSheT9SPowCfZf01
QXFtpEkyBQcQPj66EF/+QX4=
=mWbn
-----END PGP SIGNATURE-----