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:
>
> 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
On 2/3/2020 6:21 PM, Chris Angelico wrote:
Hmm, true, although that's equivalent only in one specific situation.
In mathematics, "congruent" means that two things are functionally
equivalent (eg triangles with the same length sides; in programming
terms we'd probably say that two such triangles
On Mon, Feb 03, 2020 at 05:26:38PM -0800, Sebastian Berg wrote:
> 1. `==` has of course the logic `NaN == NaN -> False`
> 2. `PyObject_RichCompareBool(a, b, Py_EQ)` was argued to have a useful
>logic of `a is b or a == b`. And I argued that you could define:
>
>def
On Tue, Feb 4, 2020 at 1:08 PM Steven D'Aprano wrote:
>
> On Tue, Feb 04, 2020 at 12:33:44PM +1100, Chris Angelico wrote:
>
> [Sebastian Berg]
> > > But if `PyObject_RichCompareBool(..., Py_EQ)` is such a fundamental
> > > operation (and in a sense it seems to me that it is), is there a point
> >
On Tue, Feb 04, 2020 at 12:33:44PM +1100, Chris Angelico wrote:
[Sebastian Berg]
> > But if `PyObject_RichCompareBool(..., Py_EQ)` is such a fundamental
> > operation (and in a sense it seems to me that it is), is there a point
> > in explicitly defining it?
> >
> > That would mean adding
On Tue, Feb 4, 2020 at 10:12 AM Sebastian Berg
wrote:
>
> Now, probably this has been rejected a hundred times before, and there
> are some very good reason why it is a horrible thought...
>
> But if `PyObject_RichCompareBool(..., Py_EQ)` is such a fundamental
> operation (and in a sense it seems
On Mon, 2020-02-03 at 16:43 -0800, Larry Hastings wrote:
> On 2/3/20 3:07 PM, Sebastian Berg wrote:
> > That would mean adding `operator.equivalent(a, b) -> bool` which
> > would
> > allow float to override the result and let
> > `operator.equivalent_value(float("NaN"), float("NaN))` return True;
On 2/3/20 3:07 PM, Sebastian Berg wrote:
That would mean adding `operator.equivalent(a, b) -> bool` which would
allow float to override the result and let
`operator.equivalent_value(float("NaN"), float("NaN))` return True;
luckily very few types would actually override the operation.
You
Now, probably this has been rejected a hundred times before, and there
are some very good reason why it is a horrible thought...
But if `PyObject_RichCompareBool(..., Py_EQ)` is such a fundamental
operation (and in a sense it seems to me that it is), is there a point
in explicitly defining it?
[Tim]
>> PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut: if x
>> and y are the same object, then equality comparison returns True
>> and inequality False. No attempt is made to execute __eq__ or
>> __ne__ methods in those cases.
>> ...
>> If it's intended that Python-the-language
+1 on everything Raymond says here (and in his second message).
I don't see a need for more classes or ABCs.
On Mon, Feb 3, 2020 at 00:36 Raymond Hettinger
wrote:
> > PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut: if x and
> y are the same object, then equality comparison
We could introduce parallel kinds of collections:
ValueList/IdentityList, ValueDict/IdentityDict, etc. Ones would use
comparison by value and do not preserve identity (so we could use more
efficient storage for homogeneous collections, for example a list of
small ints could spend 1 byte/item).
I forget to mention that list.index() also uses PyObject_RichCompareBool().
Given a non-empty list *s*:
s[0] = x
assert s.index(x) == 0 # We want this to always work
or:
s = [x]
assert s.index(x) == 0# Should not raise a ValueError
If those two assertions aren't
> PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut: if x and y are
> the same object, then equality comparison returns True and inequality False.
> No attempt is made to execute __eq__ or __ne__ methods in those cases.
>
> This has visible consequences all over the place, but they
On 24/01/2020 21:01, Terry Reedy wrote:
On 1/24/2020 7:09 AM, Steven D'Aprano wrote:
On Fri, Jan 24, 2020 at 05:45:35AM -0500, Terry Reedy wrote:
On 1/24/2020 3:36 AM, Victor Stinner wrote:
CPython current behavior rely on the fact that it's possible to get
the memory address of an object.
On 1/24/2020 8:43 PM, Tim Peters wrote:
[Terry Reedy ]
]& skipping all the parts I agree with]
...
Covered by "For user-defined classes which do not define __contains__()
but do define __iter__(), x in y is True if some value z, for which the
expression x is z or x == z is true, is produced
[Terry Reedy ]
]& skipping all the parts I agree with]
> ...
> Covered by "For user-defined classes which do not define __contains__()
> but do define __iter__(), x in y is True if some value z, for which the
> expression x is z or x == z is true, is produced while iterating over y.
> " in
>
>
On 1/24/2020 5:29 PM, Tim Peters wrote:
[Terry Reedy ]
...
It is, in the section on how to understand and use value comparison
*operators* ('==', etc.).
https://docs.python.org/3/reference/expressions.html#value-comparisons
First "The default behavior for equality comparison (== and !=) is
[Tim]
>> I think it needs more words, though, to flesh out what about this is
>> allowed by the language (as opposed to what CPython happens to do),
>> and to get closer to what Guido is trying to get at with his
>> "*implicit* calls". For example, it's at work here, but there's not a
>> built-in
25.01.20 00:29, Tim Peters пише:
I think it needs more words, though, to flesh out what about this is
allowed by the language (as opposed to what CPython happens to do),
and to get closer to what Guido is trying to get at with his
"*implicit* calls". For example, it's at work here, but there's
On Sat, Jan 25, 2020 at 9:40 AM Tim Peters wrote:
> I think it needs more words, though, to flesh out what about this is
> allowed by the language (as opposed to what CPython happens to do),
> and to get closer to what Guido is trying to get at with his
> "*implicit* calls". For example, it's at
[Terry Reedy ]
> ...
> It is, in the section on how to understand and use value comparison
> *operators* ('==', etc.).
> https://docs.python.org/3/reference/expressions.html#value-comparisons
>
> First "The default behavior for equality comparison (== and !=) is based
> on the identity of the
[Inada Naoki ]
> FWIW, (list|tuple).__eq__ and (list|tuple).__contains__ uses it too.
> It is very important to compare recursive sequences.
>
> >>> x = []
> >>> x.append(x)
> >>> y = [x]
> >>> z = [x]
> >>> y == z
> True
That's a visible consequence, but I'm afraid this too must be
considered an
On 1/24/2020 7:09 AM, Steven D'Aprano wrote:
On Fri, Jan 24, 2020 at 05:45:35AM -0500, Terry Reedy wrote:
On 1/24/2020 3:36 AM, Victor Stinner wrote:
CPython current behavior rely on the fact that it's possible to get
the memory address of an object.
No, this behavior relies on the
On 1/24/2020 7:09 AM, Steven D'Aprano wrote:
On Fri, Jan 24, 2020 at 05:45:35AM -0500, Terry Reedy wrote:
On 1/24/2020 3:36 AM, Victor Stinner wrote:
CPython current behavior rely on the fact that it's possible to get
the memory address of an object.
No, this behavior relies on the
Terry Reedy wrote:
> On 1/24/2020 4:23 AM, Paul Moore wrote:
> > On Fri, 24 Jan 2020 at 02:36, Guido van Rossum gu...@python.org wrote:
> > I'm tempted to declare this
> > implementation-defined behavior -- implicit calls to __eq__ and __ne__
> > may be skipped if both sides are the same object
On Fri, Jan 24, 2020 at 4:47 AM Steven D'Aprano wrote:
> On Fri, Jan 24, 2020 at 10:57:11PM +1100, Chris Angelico wrote:
> > On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano
> wrote:
> > >
> > > The only thing I'm unsure of here is whether direct use of the `==` and
> > > `!=` operators are
On Fri, Jan 24, 2020 at 3:45 AM Steven D'Aprano wrote:
> On Fri, Jan 24, 2020 at 12:36:13PM +0300, Ivan Pozdeev via Python-Dev
> wrote:
>
> > >I'm tempted to declare this implementation-defined behavior --
> *implicit*
> > >calls to __eq__ and __ne__ *may* be skipped if both sides are the same
>
On Fri, Jan 24, 2020 at 12:36 AM Victor Stinner wrote:
> Le ven. 24 janv. 2020 à 03:37, Guido van Rossum a
> écrit :
> > I think this started with a valuable optimization for `x in `. I
> don't know if that was ever carefully documented, but I remember that it
> was discussed a few times (and
On Fri, 24 Jan 2020 at 11:15, Terry Reedy wrote:
>
> On 1/24/2020 4:23 AM, Paul Moore wrote:
> > We could add an extra clause here: """As an optimisation, when the
> > implementation *implicitly* compares two values for equality (for
> > example, in list comparison or `list.count`) it is allowed
On Fri, Jan 24, 2020 at 10:57:11PM +1100, Chris Angelico wrote:
> On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano wrote:
> >
> > The only thing I'm unsure of here is whether direct use of the `==` and
> > `!=` operators are included as "implicit calls" to the dunders. I
> > *think* I understand
24.01.20 13:57, Chris Angelico пише:
Are there any non-container uses where this comes up? Can the rule be
codified simply as that container membership, in all core/stdlib
types, is defined by "x is y or x == y"?
Also a membership test for iterators (which is already explicitly
documented).
On Fri, Jan 24, 2020 at 05:45:35AM -0500, Terry Reedy wrote:
> On 1/24/2020 3:36 AM, Victor Stinner wrote:
> >CPython current behavior rely on the fact that it's possible to get
> >the memory address of an object.
>
> No, this behavior relies on the language specification that all objects
>
On Fri, Jan 24, 2020 at 10:44 PM Steven D'Aprano wrote:
>
> The only thing I'm unsure of here is whether direct use of the `==` and
> `!=` operators are included as "implicit calls" to the dunders. I
> *think* I understand Guido's intention, but I'm not sure:
>
> * x == y MUST call `__eq__`
>
> *
On Fri, Jan 24, 2020 at 12:36:13PM +0300, Ivan Pozdeev via Python-Dev wrote:
> >I'm tempted to declare this implementation-defined behavior -- *implicit*
> >calls to __eq__ and __ne__ *may* be skipped if both sides are the same
> >object depending on the whim of the implementation.
>
> This
On 1/24/2020 4:23 AM, Paul Moore wrote:
On Fri, 24 Jan 2020 at 02:36, Guido van Rossum wrote:
I'm tempted to declare this implementation-defined behavior -- *implicit* calls
to __eq__ and __ne__ *may* be skipped if both sides are the same object
depending on the whim of the implementation.
On 1/24/2020 3:36 AM, Victor Stinner wrote:
Le ven. 24 janv. 2020 à 03:37, Guido van Rossum a écrit :
I think this started with a valuable optimization for `x in `. I don't
know if that was ever carefully documented, but I remember that it was discussed a
few times (and IIRC Raymond was
On Thu, Jan 23, 2020 at 07:29:58PM -0600, Tim Peters wrote:
> PyObject_RichCompareBool(x, y, op) has a (valuable!) shortcut: if x
> and y are the same object, then equality comparison returns True and
> inequality False. No attempt is made to execute __eq__ or __ne__
> methods in those cases.
>
On 1/24/2020 3:12 AM, Victor Stinner wrote:
IMO it's a good optimization to skip __eq__() when id(x) == id(y).
From a higher level viewpoint, what is being skipped is literally doing
'x == y'.
But
it can be surprising, so I just would like to document it somewhere.
It is, in the section
On 24.01.2020 5:36, Guido van Rossum wrote:
Good question!
I think this started with a valuable optimization for `x in `. I don't know if that was ever carefully documented, but I remember
that it was discussed a few times (and IIRC Raymond was adamant that this should be so optimized --
On Fri, 24 Jan 2020 at 02:36, Guido van Rossum wrote:
> I'm tempted to declare this implementation-defined behavior -- *implicit*
> calls to __eq__ and __ne__ *may* be skipped if both sides are the same object
> depending on the whim of the implementation.
This sounds reasonable to me. It
24.01.20 10:29, Serhiy Storchaka пише:
Even Python implementations
like collections.abc.Sequence and collections.abc.Mapping were changed
to use `x is y or x == y` instead of just `x == y` few versions ago.
https://bugs.python.org/issue26915
___
Le ven. 24 janv. 2020 à 03:37, Guido van Rossum a écrit :
> I think this started with a valuable optimization for `x in `. I don't
> know if that was ever carefully documented, but I remember that it was
> discussed a few times (and IIRC Raymond was adamant that this should be so
> optimized
On Fri, Jan 24, 2020 at 5:24 PM Victor Stinner wrote:
>
> You're right that it's not only about list.count().
>
> list.count(), list.index(), tuple.count() and tuple.index() all
> consider that two elements are equal if id(x) == id(y):
>
FWIW, (list|tuple).__eq__ and (list|tuple).__contains__
24.01.20 03:29, Tim Peters пише:
If it's intended that Python-the-language requires this, that needs to
be documented.
I think it is already documented somewhere. Even Python implementations
like collections.abc.Sequence and collections.abc.Mapping were changed
to use `x is y or x == y`
You're right that it's not only about list.count().
IMO it's a good optimization to skip __eq__() when id(x) == id(y). But
it can be surprising, so I just would like to document it somewhere.
For example, in __eq__() method documentation:
On Thu, 2020-01-23 at 18:36 -0800, Guido van Rossum wrote:
> Good question!
>
It is, below mostly lamenting, so just to say my personal gut feeling
would be that it should probably be considered an "implementation
detail" that this used e.g. by most containers. But besides that it
leads to
Good question!
I think this started with a valuable optimization for `x in `. I
don't know if that was ever carefully documented, but I remember that it
was discussed a few times (and IIRC Raymond was adamant that this should be
so optimized -- which is reasonable).
I'm tempted to declare this
48 matches
Mail list logo
