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

[Philipp von Weitershausen]

Dr. Volker Jaenisch wrote:
> 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:
> "

This is not from my book.

> 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()

Because Python's mapping interface says it's called .keys(), it's as 
simple as that. I have a hard time seeing the relation of some text 
about Zope coding style and a standard Python API that's been around for 
decades.

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

BTrees *do* have a method iterkeys() which works similarly to keys(), 
except that it returns an actualy Python 2.2 style iterator.

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

As said, BTrees already have an iterkeys() method and feel free to use 
it. As far as the keys() method is concerned, that's important legacy. 
Other than letting a few folks every so often stumble over its behaviour 
when mutating the mapping as you iterate over it, I don't think it does 
much harm. And even in that case, people will find a solution or else 
they come to a mailinglist and they'll be helped. Big deal. No need to 
make a big fuss out of the BTree API now. If something's rock stable 
then it's that API.


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