The only reason I can think of for wanting this simple class in the stdlib would be that on GIL-free Python implementations you could replace it with a lock-free version. But I think we'd probably want to rethink a bunch of other datastructures to be lock-free, and a 3rd party package on PyPI makes more sense to me than jumping right into the stdlib.
On Thu, Aug 25, 2016 at 11:10 AM, Ben Hoyt benhoyt@gmail.com wrote:
As long as Python uses a GIL to protect C level function
calls, you can use an iterator for this:
import itertools x = itertools.count() ... mycount = next(x)
Yeah, that's a neat hack -- I saw it recommended on StackOverflow, and saw it used in the standard library somewhere. I think that's probably okay in the *CPython* stdlib, because it's CPython so you know it has the GIL. But this wouldn't work in other Python implementations, would it (IronPython and Jython don't have a GIL). Or when itertools.count() is implemented in pure Python on some system? Seems like it could blow up in someone's face when they're least expecting it. I also think using *iter*tools is a pretty non-obvious way to get a thread-safe counter.
-Ben
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/