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

[Dr. Volker Jaenisch]

Hi Brandon!

Brandon Craig Rhodes schrieb:
>>> ME VOLKER ASK BUG OR FEATURE? VOLKER NO LIKE BUG! VOLKER NO LIKE FEATURE!
>>>       
>
> Hilarious!  What a fun mailing list I've joined.  Volker is my
> favorite so far.
>   
VOLKER HAPPY :-)
>> 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.
>>     
>
> Nonsense.  If Volker is unhappy getting a huge list from .keys(), he
> can call .iterkeys() instead.  Please review the Python interface for
> mapping types; it says explicitly that .keys() returns:
>
>    "a copy of a's list of keys"
>   
VOLKER SAY GOTCHA!

To quote Philipps zope3 book:
"
    private and protected attributes and methods (including built-in
ones, like init ).
    Classes always start with upper case with exception of ZCML
directives, which is a
    special case. Attribute and method names always begin with a lower
letter, whereby
    a method should always start with a verb. Here is an example of
these rules:
"
so from the perspective of good zope3 coding style

.keys()

is suboptimal since it does not start with a verb. Why not naming it
.getIterator() or .getKeyIterator()

It is common sense for good coding style that the name of a method
should reflect what the method does.
.keys() does not return a _static_ list of keys as .keys() of python
dicts. It returns an iterator representing the actual set of keys.

To quote Philipp:
> * It's not called iterkeys() because our BTree implementation in the 
ZODB has been around for about 10 years.

I understand that in the following way: At the time the ZODB was
developed it may have been the best choice to name it.
So this is no reason not to give it a better name.

Why not remane it to iterkeys() or getIterator() and declare .keys() in
the ZODB to be deprecated?

VOLKER NO LAWYER! VOLKER SMASH LAWYERS!

But if we like to sell Zope3/Grok we do us and our users a favour if we
guide them
the best way we can.

Maybe some of you know the O'Reilly Book "learning python". I liked this
book very much since in every chapter
there was a subchapter concerning pitfalls and gotchas.

VOLKER TRAPPED! VOLKER SHOW GOTCHA! VOLKER HELP GROK!

Best Regards,

Volker

-- 
====================================================
   inqbus it-consulting      +49 ( 341 )  5643800
   Dr.  Volker Jaenisch      http://www.inqbus.de
   Herloßsohnstr.    12      0 4 1 5 5    Leipzig
   N  O  T -  F Ä L L E      +49 ( 170 )  3113748
====================================================