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

[Brandon Craig Rhodes]

Philipp von Weitershausen <philipp at weitershausen.de> writes:

> Brandon Craig Rhodes wrote:
>
>> If Volker is unhappy getting a huge list from .keys(), he can call
>> .iterkeys() instead.  Please review the Python interface for
>> mapping types...
>
> When the BTree mapping type was conceived, Python didn't know
> iterators ... it's a combination of efficiency and legacy ...  It's
> not called iterkeys() because our BTree implementation in the ZODB
> has been around for about 10 years.

Please understand that my criticism here is a very modest one; I would
never criticize someone for not being able to guess ahead of time what
lazy dictionary iterators were going to be named! :-)

My only wish is to support the Volker - who was, after all, quite
funny, and deserves our support - in two quite modest contentions:

 - The .keys() method of BTrees should never have been named .keys()
   because, even back at the time it was first written, it conflicted
   with a Python convention for how .keys() behaves, and consequently
   broke several common programming idioms.  It would have been far
   friendlier not to have .keys() at all than to provide a
   non-standard one.

   Having the programmer remember "this class is wierd and I have to
   call (for example) .travelkeys() rather than .keys()" is no more
   difficult than having them remember ".keys() on this class is
   actually a dynamic traversal that breaks common idioms", and has
   the vast benefit that if they forget and try to call .keys(), they
   would get a straightforward error to remind them that "This Class
   Is Different", rather than getting strange results.

 - Now that Python has in fact grown its own lazy-iteration protocol,
   BTrees should move to adopt it; at the very least, BTrees should
   grow an .iterkeys() method which could begin as a synonym for the
   current .keys() function, so that new code can begin using plain
   Python idiom.  Readability would at least be enhanced, even if no
   one could agree upon a timetable for ever having .keys() revert to
   Pythonic behavior.

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon