On Tue, 2020-02-04 at 13:44 +1100, Steven D'Aprano wrote: > On Mon, Feb 03, 2020 at 05:26:38PM -0800, Sebastian Berg wrote: > <snip>
> If you want to argue that "identical or equal" is such a fundamental
> and
> important operation in Python code that we ought to offer it ready-
> made
> in the operator module, I'm listening. But my gut feeling here is to
> say
> "not every one line expression needs to be in the stdlib".
>
Probably, yes. I am only semi seriously suggesting it. I am happy to
get to the conclusion: NumPy is weird and NaNs are a corner case that
you just have to understand at some point.
Anyway, yes, I hinted at a dunder, I am not sure that is remotely
reasonable. And yes, I thought that if this is an important enough of a
"concept" it may make sense to bless it with a python side function.
> PyObject_RichCompareBool is a different story. "Identical or equal"
> is
> not so simple to implement correctly in C code, and it is a common
Of course, it is just as simple C. If PyObject_RichCommpareBool would
simply not include the identity check, in which case it is identical to
`bool(a == b)` in python. (Which of course would be annoying to have to
type out.)
>
> operation used in lists, tuples, dicts and possibly others, so it
> makes
> sense for there to be a C API for it.
>
>
> > and resolves current inconsistencies w.r.t. containers and NaNs.
>
> How does it resolve these (alleged) inconsistencies?
>
The alleged inconsistencies (which may be just me) are along these
lines (plus those with NumPy):
import math
print({math.inf - math.inf for i in range(100})
print({math.nan for i in range(10)})
maybe I am alone to perceive that as an inconsistency. I _was_ saying
that if you had a dunder, for this you could enforce that:
* `a is b` implies `congruent(a, b)`
* `a == b` implies `congruent(a, b)`
* `hash(a) == hash(b)` implies `congruent(a, b)`.
So the "inconsistencies" are that of course `hash(NaN)` and `NaN is
NaN` fail to imply `NaN == NaN`, while congruent could be enforced to
do it "right".
Chris said it much better anyway, and is probably right to disregard
the dunder part:
1. Name the current operation (congruent?) to reason about it?
2. Bless it with its own function? (helps maybe documenting it)
3. Consider if its worth resolving the above inconsistencies by making
it an operator with a dunder.
I am happy to stop at 0 :). I am sure similar discussions about the
hash of NaN come up once a year.
- Sebastian
> The current status quo is that containers perform operations such as
> equality by testing for identity or equality, which they are
> permitted
> to do and is documented. Changing them to use your "identical or
> equal"
> API will (as far as I can see) change nothing about the semantics,
> behaviour or even implementation (since the C-level containers like
> list
> will surely still call PyObject_RichCompareBool rather than a
> Python-level wrapper).
>
> So whatever inconsistencies exist, they will still exist.
>
> If I have missed something, please tell me.
>
>
>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YEZTWEH7B3SPBV2GIBOOXC2OGWC2CM2T/ Code of Conduct: http://python.org/psf/codeofconduct/
