Alexander Belopolsky wrote: > Changing the subject to reflect branched discussion and forwarding to > python-ideas where it probably belongs. > > On Mon, Oct 26, 2009 at 12:02 PM, Terry Reedy <tjreedy at udel.edu> wrote: >> Alexander Belopolsky wrote: >> >>> Here is an alternative idea on how storing interned objects in a set >>> can be supported. Currently set.add method returns None and has no >>> effect when set already has an object equal to the one being added. I >>> propose to consider changing that behavior to make set.add return the >>> added object or the set member that is equal to the object being >>> added. It is unlikely that many programs rely on the return value >>> being None (with doctests being a probable exception), so adding this >>> feature is unlikely to cause much grief. >> I had exactly the same idea, but did not post because it violates the >> general rule that mutators return None. > > Is there such a rule? What about set/dict pop? The rule perhaps should be restated as 'Collection mutators return None or possible an item but not the collection.' >> On the other hand, the returned >> value here would not be the mutated collection, so no chaining is possible. >> And 'add' is clearly intended to change something. >> > Is this an argument for or against the proposal? Mildly for. >> On the other hand, frozensets do not have an add method. > > However, PySet_Add "works with frozenset instances (like > PyTuple_SetItem() it can be used to fill-in the values of brand new > frozensets before they are exposed to other code). " > <http://docs.python.org/3.1/c-api/set.html#PySet_Add> > > I will experiment with changing PySet_Add to see how much it would > break and whether it will be helpful in implementing set-based > interning of python strings. Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4