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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4