[Grok-dev] Re: Iterativly emptying a grok.container shows weird
Philipp von Weitershausen
philipp at weitershausen.de
Tue Jun 12 19:45:16 EDT 2007
Dr. Volker Jaenisch wrote:
> Hi Kevin!
> Kevin Teague schrieb:
>> Python 3 will have dict.keys() return an iterator and not a list:
> 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  <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
More information about the Grok-dev