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 <benh...@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/ > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/