<p>There's not much chance of that now, most projects that could  cause trouble with this are using six, or moving up from 2. By comparison many other things in Python 3.3 are very non backwards friendly like delegating generators, new exception hierarchy, and a crap load of new API calls. Now is the hour! :></p>

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