> I want a real-world application which requires it.
> Without a strong use case, I think the discussion is just wasting time.
I would have to agree. Initially I was in support of changing the behavior, but
upon reading the responses of several core developers and further
consideration, the most
On Fri, Jul 26, 2019 at 2:03 PM Random832 wrote:
>
>
> Items also sometimes contains unhashable types, and some methods simply fail
> in that case. I suggest that this precedent provides a way forward -
> implement the entire intuitive "contains the same amount of each value"
> algorithm [more
On Fri, Jul 26, 2019, at 00:22, Ivan Pozdeev via Python-Dev wrote:
> Since a hash table is an unordered container and keys(), items() and
> values() are iterators over it, *I would expect the results of any of
> the comparisons to be undefined.*
keys, items, and values are not iterators. They ar
On 23.07.2019 23:59, Kristian Klette wrote:
Hi!
During the sprints after EuroPython, I made an attempt at adding support for
comparing the results from `.values()` of two dicts.
Currently the following works as expected:
```
d = {'a': 1234}
d.keys() == d.keys()
d.items() == d.items()
```
bu
On Thu, Jul 25, 2019 at 4:35 AM Petr Viktorin wrote:
> It's not the equality operator that errors: `==` means element-wise
> comparison in Numpy. The error would come from a conversion of the array
> to bool:
>
> >>> numpy.array([1, 2, 3]) == numpy.array([1, 3, 4])
> array([ True, False, False])
David Mertz wrote:
This feels similar to NumPy arrays, that also will not compare for
equality in bare form.
Not quite the same -- comparing numpy arrays doesn't raise an exception,
it returns an array of booleans. What raises an exception is trying to
use the resulting array in a boolean conte
25.07.19 23:19, Kyle Stanley пише:
Serhiy Storchaka wrote:
Actually, the == operator cannot return NotImplemented.
Thanks for the clarification. What is the reason for this limitation and is it
only possible for the `==` operator to return one of `None`, `False`, or `True`?
The `==` operato
On 7/25/2019 4:19 PM, Kyle Stanley wrote:
Serhiy Storchaka wrote:
Actually, the == operator cannot return NotImplemented.
Thanks for the clarification. What is the reason for this limitation and is it
only possible for the `==` operator to return one of `None`, `False`, or
`True`? It seems
Terry Reedy wrote:
> Given the absence of a consensus on when values() views should be
> considered equal, I strongly agree. I strongly oppose raising an exception.
I am with you regarding the strong opposition regarding the raising of an
exception. I don't think that the `==` operator should r
Serhiy Storchaka wrote:
> Actually, the == operator cannot return NotImplemented.
Thanks for the clarification. What is the reason for this limitation and is it
only possible for the `==` operator to return one of `None`, `False`, or
`True`? It seems like it would be useful for it to be able to
On 7/25/2019 2:46 PM, Brett Cannon wrote:
You're correct that I misspoke, but I personally still think a doc change is
the best solution.
Given the absence of a consensus on when values() views should be
considered equal, I strongly agree. I strongly oppose raising an exception.
--
Terry
25.07.19 22:05, Kyle Stanley пише:
I would agree that a doc change should occur if it is decided that the current behavior
is appropriate, but I would like to mention that in the current [documentation for
`object.__eq__()`](https://docs.python.org/3/reference/datamodel.html#object.__eq__), it
Brett Cannon wrote:
> You're correct that I misspoke, but I personally still think a doc change
> is the best solution.
I would agree that a doc change should occur if it is decided that the current
behavior is appropriate, but I would like to mention that in the current
[documentation for
`obj
Eric V. Smith wrote:
>That makes things worse. Now the comparison is always true in a boolean
>context. And presumably you'd want __ne__ to also return >NotImplemented,
>so then both __eq__ and __ne__ would be true, since >bool(NotImplemented)
>is True.
Eric V Smith wrote:
7/25/2019 6:00 AM, Er
Steven D'Aprano wrote:
> On Wed, Jul 24, 2019 at 05:30:19PM -, Brett Cannon wrote:
> > When I saw this I thought, "it should be like
> > set(d1.values()) ==
> > set(d2.values())", but has been pointed out there's no guarantee that
> > all values will be hashable.
> > The hashability requireme
On Wed, 24 Jul 2019 19:09:37 -0400
David Mertz wrote:
>
> There are various possible behaviors that might make sense, but having
> `d.values() != d.values()` is about the only one I can see no sense in.
Why? Does the following make no sense to you?
>>> iter(()) == iter(())
False
Python deliber
7/25/2019 6:00 AM, Eric V. Smith wrote:
On 7/25/2019 4:27 AM, Kyle Stanley wrote:
Serhiy Storchaka wrote:
Is there any precedence of raising an exception in the equality
comparison?
Does 3 == "3" returning False make more sense to you?
Personally, I don't find ``3 == "3"`` to be an equival
On 7/25/2019 4:27 AM, Kyle Stanley wrote:
Serhiy Storchaka wrote:
Is there any precedence of raising an exception in the equality comparison?
Does 3 == "3" returning False make more sense to you?
Personally, I don't find ``3 == "3"`` to be an equivalent comparison to
``d0.values() == d1.va
On Thu, Jul 25, 2019 at 4:01 AM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> I considered an alternative: return True if the underlying dicts were
> identical or equal, and raise an Exception otherwise.
> But I soon decided that this was a terrible idea: it could hide a bug by
> mak
On 7/25/19 2:25 AM, David Mertz wrote:
Exactly! that was my thought that the exception message could hint at
likely approaches. The NumPy example seems to have a good pattern:
arr1 == arr2
|ValueError:Thetruth value of an array withmore than one element |isambiguous.
|Usea.any()ora.all().|
Serhiy Storchaka wrote:
> Is there any precedence of raising an exception in the equality comparison?
> Does 3 == "3" returning False make more sense to you?
Personally, I don't find ``3 == "3"`` to be an equivalent comparison to
``d0.values() == d1.values()``. Generally, it makes sense when comp
25.07.19 01:15, Greg Ewing пише:
Steven D'Aprano wrote:
Currently that assertion fails. Should it? Putting aside the
convenience of "do nothing, just inherit the object.__eq__ behaviour"
do you think that the current behaviour is *correct*?
What I'm getting from this thread is that there are
22 matches
Mail list logo
