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

[Philipp von Weitershausen]

Dr. Volker Jaenisch wrote:
> Hi Kevin!
> Kevin Teague schrieb:
>>
>> Python 3 will have dict.keys() return an iterator and not a list:
>>
>> http://www.python.org/dev/peps/pep-3106/
> That is quite interesting.
> 
> To quote the PEP:
>> The original plan was to simply let .keys(), .values() and .items() 
>> return an iterator, i.e. exactly what iterkeys(), itervalues() and 
>> iteritems() return in Python 2.x. However, the Java Collections 
>> Framework [1] <http://www.python.org/dev/peps/pep-3106/#id3> suggests 
>> that a better solution is possible: the methods return objects with 
>> set behavior (for .keys() and .items()) or multiset (== bag) behavior 
>> (for .values()) that do not contain copies of the keys, values or 
>> items, but rather reference the underlying dict and pull their values 
>> out of the dict as needed.
> So .keys() will not return an iterator but a set like operator which 
> also behaves like an iterator.
> This is from my opinion not exactly what OOBTreeIterator is.

Actually, the .keys() and .items() methods of BTrees return *exactly* 
what Py3k dictionaries will return: a shallow view object on the actual 
mapping that is iterable. I've also personally heard Guido say several 
times that mutating the underlying dictionary while iterating over its 
view obtained from .keys() or .items() will have no pre-defined result 
and may lead to errors.

I think BTrees are well within the limits.

> People mingle Lists with Arrays, Pointers with References do a lot of harm.
> Lets name different things different. Nothing is more dangerous than 
> things that are quite the same.

BTrees already ahve a different name than dictionaries. Containers 
(which are mappings with string or unicode keys) also have different 
names. They all comply with Python's mapping interface as far as duck 
typing is concerned.


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