[Python-Dev] Re: Sets: elt in dict, lst.include

[M.-A. Lemburg]

Tim Peters wrote:
> 
> [Tim]
> >> Seems an unrelated topic:  would "iterators for dictionaries" solve the
> >> supposed problem with iteration order?
> 
> [MAL]
> > 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) 
problem.

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

	http://www.lemburg.com/python/mxPython-1.5.patch.gz
 
> > 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).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/