Hi I was wondering why threading.Event hasn't got the __nonzero__ special attribute? I think it would allow for code to be more pythonic if you could just do "if e: ..." instead of "if e.isSet(): ..." (or "if e.is_set(): ..." in 2.6+). The patch is trivial: Index: Lib/threading.py =================================================================== --- Lib/threading.py (revision 72551) +++ Lib/threading.py (working copy) @@ -371,6 +371,9 @@ is_set = isSet + def __nonzero__(self): + return self.__flag + def set(self): self.__cond.acquire() try: Is it worth submitting this to the tracker or is there some reason why this is a bad idea that I've missed? Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org
On Sun, May 10, 2009, Floris Bruynooghe wrote:
Please submit to the tracker so that even if it *is* a bad idea it will get recorded. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan
On Sun, May 10, 2009 at 10:20:16AM -0700, Aahz wrote:
http://bugs.python.org/issue5998 Regarsds Floris
Floris Bruynooghe <floris.bruynooghe@...> writes:
Is it worth submitting this to the tracker or is there some reason why this is a bad idea that I've missed?
First, __nonzero__ should only be used when the notion of a truth value is obvious. I'm not sure it is the case here, although I don't find it shocking. Second, adding it would break compatibility for code using "if not event" as a shorthand for "if event is None". In any case, as Aahz said, please file a bug in the tracker. Regards Antoine.
Floris Bruynooghe wrote:
2.6 and 3.1 are feature frozen. I think the proposal should be to add __bool__ to 3.2 and maybe backport to 2.7 as __nonzero__. It is possible that 3.2 will get new features not added to 2.7, but I doubt the opposite.
Since you have a patch that people could grab and apply, and not just an idea, I say submit too. tjr
Floris Bruynooghe <floris.bruynooghe@...> writes:
-1 As with Antoine, I find conflating an Event's flag with its boolean value confusing. I also don't see other precedent for this in the standard library. (locks for example)
On Sun, May 10, 2009, Floris Bruynooghe wrote:
Please submit to the tracker so that even if it *is* a bad idea it will get recorded. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan
On Sun, May 10, 2009 at 10:20:16AM -0700, Aahz wrote:
http://bugs.python.org/issue5998 Regarsds Floris
Floris Bruynooghe <floris.bruynooghe@...> writes:
Is it worth submitting this to the tracker or is there some reason why this is a bad idea that I've missed?
First, __nonzero__ should only be used when the notion of a truth value is obvious. I'm not sure it is the case here, although I don't find it shocking. Second, adding it would break compatibility for code using "if not event" as a shorthand for "if event is None". In any case, as Aahz said, please file a bug in the tracker. Regards Antoine.
Floris Bruynooghe wrote:
2.6 and 3.1 are feature frozen. I think the proposal should be to add __bool__ to 3.2 and maybe backport to 2.7 as __nonzero__. It is possible that 3.2 will get new features not added to 2.7, but I doubt the opposite.
Since you have a patch that people could grab and apply, and not just an idea, I say submit too. tjr
Floris Bruynooghe <floris.bruynooghe@...> writes:
-1 As with Antoine, I find conflating an Event's flag with its boolean value confusing. I also don't see other precedent for this in the standard library. (locks for example)
participants (5)
-
Aahz -
Antoine Pitrou -
Benjamin Peterson -
Floris Bruynooghe -
Terry Reedy