Christopher Barker writes:
On Mon, Jun 29, 2020 at 1:53 AM Stephen J. Turnbull < firstname.lastname@example.org> wrote:
But if it turns out that somebody *wants* to check "2 is 2.0", this .add_unique can serve both purposes.
can it though?
(or should it?)
YMMV, but I think that's not our call. This check *can* be done without this facility, but AFAICS it would be O(n) (iterate over the set, testing for equality, then testing for identity if found). Providing this function simply optimizes that to O(1).
The argument against this isn't "should we distinguish int from float in principle", it's "should we bother with a status return at all" and "if we bother, why not KISS with a boolean return", don't you think?
-- the fact is that it was decided the 2 and 2.0 are equivalent as members of a set (which makes great sense, there are they SAME number, and the difference is an implementation detail),
No, it's not just an implementation detail. If 2.0 can sneak into an integer set, so can Inf and Nan, but any integer calculation using members of that set will not be prepared for that. And it's possible that 2.00000000001 can sneak in as well, changing an exact integer calculation into floating point calculation with rather different rules.
This is the same kind of argument used to justify zip(strict=True). I.e, this only happens if there's a programmer error, and if it does, the feature helps to debug that error.
I've lost track, but the answer to
a_set.add_unique(2) should always be the same as a_set.add_unique(2.0)
for the same set.
True. What about that? That's what makes it possible to tell whether you added the same object or merely an equal one. I don't have time to think carefully about it, but it now occurs to me to spell add_unique as "intern", as in the idiom
x = a_set.intern(x)
Of course we already have this for str, but only str, with sys.intern. It would likely be a rare use case compared to strings, but in theory any immutable could benefit from this.