On Fri, Jul 26, 2019, at 05:45, Steven D'Aprano wrote:
> Nor should we make too much of the fact that Python sets require
> elements to be hashable. As Java TreeSet demonstrates, we could get an
> efficient set of unhashable items if we required orderability; and we
> can get sets of
Kristian Klette schrieb am 23.07.19 um 22:59:
> 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() ==
Steven D'Aprano writes:
> Under what circumstances would you expect two unordered collections of
> values:
>
> {1, 2, 3, 1, 1, 1}
> {1, 2, 3, 2, 2, 2}
>
> to compare equal?
As you've pointed out yourself, I believe, here we are not interested
in generic unordered collections.
On Sun, Jul 28, 2019 at 10:18:56PM +0200, Antoine Pitrou wrote:
> On Fri, 26 Jul 2019 20:28:05 +1000
> Steven D'Aprano wrote:
> > So there are no conceptual problems in defining equality for value
> > views. Putting aside efficiency, this is easy to solve.
>
> Right. It's just waiting for
On Fri, 26 Jul 2019 20:28:05 +1000
Steven D'Aprano wrote:
> So there are no conceptual problems in defining equality for value
> views. Putting aside efficiency, this is easy to solve.
Right. It's just waiting for someone's PR. However, that doesn't mean
that the current behaviour is
On 7/26/2019 8:24 AM, Greg Ewing wrote:
Steven D'Aprano wrote:
But the basic semantics hasn't really changed: two (multi)sets of
values are equal if they have the same individual values, regardless
of order.
Why regardless of order? Dicts have an ordering nowadays. Why
shouldn't that
On Fri, Jul 26, 2019 at 08:41:40PM +0900, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > The hashability requirement for sets is, in a sense, an implementation
> > detail. It might be a requirement for sets in Python the language,
> > but its not a requirement for abstract "sets
Steven D'Aprano wrote:
But the basic semantics hasn't
really changed: two (multi)sets of values are equal if they have the
same individual values, regardless of order.
Why regardless of order? Dicts have an ordering nowadays. Why
shouldn't that ordering be reflected in the algorithm for
Steven D'Aprano wrote:
Equality tests really ought not to fail. If they do fail, it should be
considered a bug in the __eq__ method, not an intentional result.
> To allow == tests to fail is just a way of sneaking in a three-value
> logic into the language, only using an extremely
Random832 wrote:
implement the entire intuitive "contains the same amount of each value"
algorithm [more or less Counter(obj1) == Counter(obj2)],
But then we'd be guessing that this particular interpretation of
"dict values equality", out of several plausible ones, is the one
the programmer
Steven D'Aprano writes:
> The hashability requirement for sets is, in a sense, an implementation
> detail. It might be a requirement for sets in Python the language,
> but its not a requirement for abstract "sets of values".
>
> In this case, they need to be multisets, since
>
> {'a':
On Thu, Jul 25, 2019 at 10:15:15AM +1200, Greg Ewing wrote:
> What I'm getting from this thread is that there are a variety of
> possible behaviours for dict values comparison, any of which could
> be considered "correct" depending on what the programmer is trying
> to do.
Can you elaborate on
Kyle Stanley wrote:
Serhiy Storchaka wrote:
Actually, the == operator cannot return NotImplemented.
What is the reason for this limitation
It's not a limitation, it's a consequence of the way the operator
machinery works. NotImplemented is used by operator methods to
signal to the
On Wed, Jul 24, 2019 at 12:36:29PM +0200, Ronald Oussoren wrote:
>
>
> Op 24 jul. 2019 om 02:27 heeft Steven D'Aprano het
> volgende geschreven:
>
> > But I can suggest at least one useful invariant. If a, b are two dicts:
> >
> >a.items() == b.items()
> >
> > ought to be equivalent to:
On Thu, Jul 25, 2019 at 05:53:47PM +0200, Antoine Pitrou wrote:
> 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
On Wed, Jul 24, 2019 at 08:25:31PM -0400, 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: The truth value of an array with more than one element is
>
On Fri, Jul 26, 2019 at 12:57:42AM -0400, Random832 wrote:
> 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
26.07.19 08:27, Inada Naoki пише:
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
> 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
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
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()
```
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
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 `==`
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
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
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
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,
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
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
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
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() ==
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
>
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
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
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
making faulty code work intermittently.
Apologies for doubtless belabouring the blindingly obvious
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: The truth value of an array with more than one element is
ambiguous.
Use a.any() or a.all().
On Wed, Jul 24, 2019, 8:06 PM Rob
On 25/07/2019 00:09:37, David Mertz wrote:
I agree with Greg.
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.
+1
This really feels like a good cade for reading a descriptive
exception. If
I agree with Greg.
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.
This really feels like a good cade for reading a descriptive exception. If
someone wants too compare `set(d.values())` that's great.
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 a variety of
possible behaviours
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 requirement for sets is, in a sense, an
On 7/24/2019 1:30 PM, Brett Cannon wrote:
Serhiy Storchaka wrote:
o you propose? What is the use case for it?
If you want to compare dict value views as ordered sequences, it can be
surprised that d1.values() != d2.values() when d1 == d2. It will
be
inconsistent with orderless comparison of
Serhiy Storchaka wrote:
> 23.07.19 23:59, Kristian Klette пише:
> > 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() ==
On Tue, 23 Jul 2019 23:44:35 +0100
MRAB wrote:
>
> However, when comparing the values you have a problem: you have 2
> collections of objects that might contain duplicates, might not be
> hashable, and might not be sortable, so comparing them could be
> inefficient, and you can't refer back
24.07.19 13:33, Rob Cliffe via Python-Dev пише:
Naive question: Is there a way (in Python) to get at the underlying dict
from a dict.values object,
or more generally from any dict view object?
No, there is not. As well as there is no way to get at the underlying
list, tuple, dict from
On 24/07/2019 10:31:46, Steven D'Aprano wrote:
How does this seem to you? Two dict.values objects are equal if:
- they are in fact the same object (identity test on the views);
- they are both views of the same dict (identity test on the dicts);
- they are views of distinct, but equal,
Op 24 jul. 2019 om 02:27 heeft Steven D'Aprano het
volgende geschreven:
> But I can suggest at least one useful invariant. If a, b are two dicts:
>
>a.items() == b.items()
>
> ought to be equivalent to:
>
>(a.keys() == b.keys()) and (a.values() == b.values)
I don’t think this
On Tue, Jul 23, 2019 at 10:02:34PM -0400, Terry Reedy wrote:
[...]
> If one has not learned the default meaning of '==' in Python. Perhaps
> this should be given more emphasis in beginner courses. "What does it
> mean for two object to be 'equal'?" It is not a trivial question.
No, it is
On 23/07/2019 21: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()
```
23.07.19 23:59, Kristian Klette пише:
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()
```
but
On 7/23/2019 8:27 PM, Steven D'Aprano wrote:
On Tue, Jul 23, 2019 at 08:59:09PM -, 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
On Tue, Jul 23, 2019 at 08:59:09PM -, 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()
I find myself in agreement with Inada (https://bugs.python.org/issue12445), in
that comparing the values view between two dictionaries by itself would not be
particularly useful for enough people to warrant implementing the comparison.
In most situations when using the data structure, it is
On 2019-07-23 21: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()
```
58 matches
Mail list logo
