[Python-Dev] Re: Sets: elt in dict, lst.include
Wed, 31 Jan 2001 23:15:50 +0100
Tim Peters wrote:
> >> Seems an unrelated topic: would "iterators for dictionaries" solve the
> >> supposed problem with iteration order?
> > No, but it would solve the problem in a more elegant and
> > generalized way.
> I'm lost. "Would [it] solve the ... problem?" "No [it wouldn't solve the
> problem], but it would solve the problem ...". Can only assume we're
> switching topics within single sentences now <wink>.
Sorry, not my brightest day today... what I wanted to say is that
iterators would solve the problem of defining "something" in
"for something in dict" nicely.
Since iterators can define the order in which a data structure is
traversed, this would also do away with the second (supposed)
> > Besides, it also allows writing code which is thread safe, since
> > the iterator can take special actions to assure that the dictionary
> > doesn't change during the iteration phase (see the other thread
> > about "making mutable objects readonly").
> Sorry, but immutability has nothing to do with thread safety (the latter has
> to do with "doing a right thing" in the presence of multiple threads, to
> keep data structures internally consistent; raising an exception is never "a
> right thing" unless the user is violating the advertised semantics, and if
> mutation during iteration is such a violation, the presence or absence of
> multiple threads has nothing to do with that). IOW, perhaps, a critical
> section is an area of non-exceptional serialization, not a landmine that
> makes other threads *blow up* if they touch it.
Who said that an exception is raised ? The method I posted
on the mutability thread allows querying the current state just
like you would query the availability of a resource.
> > ...
> > I don't remember the figures, but these micor optimizations
> That's plural, but I thought you were talking specifically about the mutable
> counter object. I don't know which, but the two statements don't jibe.
The counter object patch is a micro-optimization and as such will
only give you a gain of a few percent. What makes the difference
is the sum of these micro optimizations.
Here's the patch for Python 1.5 which includes the optimizations:
> > do speedup loops by a noticable amount. Just compare the performance
> > of stock Python 1.5 against my patched version.
> No time now, but after 2.1 is out, sure, wrt it (not 1.5).
Python Pages: http://www.lemburg.com/python/