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 unhashable,
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() == d.i
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. W
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 someo
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 senseless
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 ordering
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 o
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
compar
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 inconvenient
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 int
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 th
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 interpre
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 f
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
> am
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 to
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 each
> 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
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
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 Cliff
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 someo
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. If
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 f
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 impl
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 key
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() == 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 to
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 corresp
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, dic
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 invar
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 not
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()
```
but
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 `d.values(
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 only
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()
```
but
58 matches
Mail list logo