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! :> On Mar 15, 2012 2:33 AM, "Guido van Rossum" guido@python.org wrote:
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)