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(
Barry Warsaw wrote:
> On Jul 23, 2019, at 12:02, Steve Dower steve.do...@python.org wrote:
> > Even if the performance impact is zero, commits that
> > span the entire codebase for not-very-impactful changes have a negative
> > impact on
> > readability (for example, someone will suddenly become r
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
14 matches
Mail list logo
