This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author josh.r
Recipients cool-RR, josh.r, rhettinger, terry.reedy
Date 2014-07-15.10:21:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1405419662.12.0.396829187699.issue20663@psf.upfronthosting.co.za>
In-reply-to
Content
The main example that comes to mind was a variant of functools.lru_cache I wrote that expired cache entries after they reached a staleness threshold. The details elude me (this was a work project from a year ago), but it was basically what I was describing; a case where I wanted to efficiently, destructively iterate a collections.deque, and it would have been nice to be able to do so without needing a lock (at least for that operation) and without (IMO) ugly infinite loops terminated by an exception. (Caveat: Like I said, this was a while ago; iter_except might only have simplified the code a bit, not saved me the lock)

No, it's not critical. But for a lot of stuff like this, the recipe saves nothing over inlining a while True: inside a try/except, and people have to know the recipe is there to even look for it. The only reason my particular example came to mind is that the atomic aspect was mildly important in that particular case, so it stuck in my head (normally I'm not trying to squeeze cycles out of Python, but performance oriented decorators are a special case). I do stuff that would be simplified by this more often, it's just cases where I currently do something else would all be made a little nicer if I could have a single obvious way to accomplish it that didn't feel oddly verbose/ugly.
History
Date User Action Args
2014-07-15 10:21:02josh.rsetrecipients: + josh.r, rhettinger, terry.reedy, cool-RR
2014-07-15 10:21:02josh.rsetmessageid: <1405419662.12.0.396829187699.issue20663@psf.upfronthosting.co.za>
2014-07-15 10:21:02josh.rlinkissue20663 messages
2014-07-15 10:21:01josh.rcreate