On Fri, Jul 26, 2019 at 7:29 PM Kyle Stanley wrote:
> > Essentially those "easy" issues aren't so easy,
> > and we're starting over.
>
> Is "easy" still going to be used for intermediate level issues or
> will it be no longer used? Apologies if this was already discussed
> in the initial thread,
> Essentially those "easy" issues aren't so easy,
> and we're starting over.
Is "easy" still going to be used for intermediate level issues or
will it be no longer used? Apologies if this was already discussed
in the initial thread, I don't have access to core-mentorship.
_
See the thread 'The trouble with "Easy" issues' in
core-mentors...@python.org. Essentially those "easy" issues aren't so easy,
and we're starting over. (That list requires subscription before you can
read it, but any core dev should be able to get a subscription.)
On Fri, Jul 26, 2019 at 6:58 PM S
> There is now a “newcomer friendly” keyword in bpo.
>
> My hope is that going forward, we can tag issues that are suitable for first
> time contributors with this keyword.
Hmmm... I haven't looked lately, but didn't there used to be an "easy"
tag which purported to serve roughly the same purpose
🍝 copy-pasta from core-mentorship mailing list.
There is now a “newcomer friendly” keyword in bpo.
My hope is that going forward, we can tag issues that are suitable for
first time contributors with this keyword.
It would be great for experienced contributors already familiar with our
workflow t
ACTIVITY SUMMARY (2019-07-19 - 2019-07-26)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7127 (+16)
closed 42314 (+42)
total 49441 (+58)
Open issues wi
Yep! That's exactly my feeling too. Maybe add these to the "reasonable"
comparisons:
sorted(d1.values()) == sorted(d2.values())
Counter(d1.values()) == Counter(d2.values())
But generally everything I might want to compare about values has a
straightforward spelling already.
On Fri, Jul 26, 2019
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
David Mertz wrote:
We COULD do that with
`d1.values() == d2.values()` in principle. This "DictValuesComparison"
object could have methods like `.equal_as_set()` and
`.equal_as_list()`. However, that's a lot of machinery for very little
gain.
Particularly as there are already perfectly go
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
21 matches
Mail list logo
