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! :>
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)