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.
On Wed, Mar 14, 2012 at 11:29 AM, Matt Joiner firstname.lastname@example.org 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" email@example.com wrote:
On Wed, Mar 14, 2012 at 10:53 AM, Masklinn firstname.lastname@example.org 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.
Python-ideas mailing list Pythonemail@example.com http://mail.python.org/mailman/listinfo/python-ideas