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 <tjre...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
