I believe I'm -0 for modifying the existing add() and +0 for a new function.
By the way, a good phrasing of the general mutating/non-mutating convention opens the built-in types section of the docs: "Some collection classes are mutable. The methods that add, subtract, or rearrange their members in place, and don’t return a specific item, never return the collection instance itself but None." Note the use of the word item, rather than any return value. Out of curiosity though, were we to change set.add(), how could we keep backwards compatibility in the c-api? On the Python level, we might find people do "val = set.add(i) or i", or even "any(set.add(i) for i in range (10))" which would break. I myself wrote the former quite often with "list.append" etc. On the c-api, the problem might be worse - I wouldn't be surprised if people use PyCheckExact or pointer comparison for the results of both PySet_Add and set_add of the set object. Is there a way to maintain compatibility on the c-api that I'm not aware of? On Fri, Jun 26, 2020, 3:41 AM Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > On 26/06/20 4:01 am, Steele Farnsworth wrote: > > My point was only that, as far as I know, all the methods for built in > > container types that serve only to change what is contained return None, > > and that this was an intentional design choice, so changing it in one > > case would have to evoke a larger discussion about what those sorts of > > methods should return. > > The reason for that convention is so that there is no confusion > about which methods return new objects and which modify the object > in place. > > However, achieving that goal only requires that mutating methods > don't return 'self'. It doesn't mean they can't return some other > value that might be useful. > > A wider argument against that might be that methods should be > classifiable into "procedures" (that have side effects but not > return values) and "functions" (that return values but don't > have side effects). I'm not sure whether that's considered part > of the Python design philosophy -- I don't remember seeing much > discussion about it. > > In this particular case, it might be better to add a new method > rather than redefining the existing 'add' method, because if code > assuming the new behaviour were run on an older version of Python, > it would fail in an obscure way. > > -- > Greg > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/ZYYUMHMD2SCNOETAPQQHDCET7JUQ5ZNZ/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SAZ5GTS6THVYUYMKU2VNE5RI3IJI3YCC/ Code of Conduct: http://python.org/psf/codeofconduct/
