I think it would actually be reasonable to return a true/false value here (there are plenty of non-threaded uses for this), except I think it's too late to change now -- it would just encourage folks from writing code that works with Python 3.3 but is very subtly broken with earlier versions. So, -1. --Guido On Wed, Mar 14, 2012 at 11:29 AM, Matt Joiner <anacrolix@gmail.com> wrote:
I should not have emphasized the atomicity here, this was not intended to be the main reason.
On Mar 15, 2012 2:11 AM, "Chris Rebert" <pyideas@rebertia.com> wrote:
On Wed, Mar 14, 2012 at 10:53 AM, Masklinn <masklinn@masklinn.net> wrote:
On 2012-03-14, at 18:36 , Matt Joiner wrote:
set.add(x) could return True if x was added to the set, and False if x was already in the set.
That does not mesh with the usual Python semantics of methods either having a side-effect (mutation) or returning a value. Why would that happen with sets but not with e.g. dicts?
The rule is a bit more complicated than that (e.g. consider list.pop()). It's gets fleshed out well in: http://bugs.python.org/issue12192
set.remove() arguably "returns" the same sort of indication as that which is proposed, in that it either raises or doesn't raise KeyError depending on whether the value was present.
But yeah, these boolean return values aren't of huge utility, particularly in the multithreaded case.
Cheers, Chris
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)