[Python-Dev] Re:  New keyword in bpo: `newcomer friendly`

[Guido van Rossum]

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, I don't have access to core-mentorship.
>

I don't know yet. You can watch updates to the devguide to find out.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6MN2F3RU5ZPH5AJCS76IF4QU3X4JVL5P/

[Python-Dev] Re:  New keyword in bpo: `newcomer friendly`

[Kyle Stanley]

> 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.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TBZUMAZPLGAJUWDOYN66RX6FW5PAZPCN/

[Python-Dev] Re:  New keyword in bpo: `newcomer friendly`

[Guido van Rossum]

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 Skip Montanaro 
wrote:

> > 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? I see an "Easy
> issues" link in the left-hand sidebar:
>
>
> https://bugs.python.org/issue?status=1&@sort=-activity&@columns=id%2Cactivity%2Ctitle%2Ccreator%2Cstatus&@dispname=Easy%20issues&@startwith=0&@group=priority=6&@action=search&@filter=&@pagesize=50
>
> This issue has the "easy" keyword:
>
> https://bugs.python.org/issue19217
>
> Are "newcomer friendly" and "easy" aimed at somewhat different targets?
>
> Skip
>
>
> Skip
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/7C6WTTBSEYETZDSP6N2JEX2F6NWL5S7E/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/N6NQGWZ3F4WRP7SWSTC3S2ERUWHJVEIH/

[Python-Dev] Re:  New keyword in bpo: `newcomer friendly`

[Skip Montanaro]

> 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? I see an "Easy
issues" link in the left-hand sidebar:

https://bugs.python.org/issue?status=1&@sort=-activity&@columns=id%2Cactivity%2Ctitle%2Ccreator%2Cstatus&@dispname=Easy%20issues&@startwith=0&@group=priority=6&@action=search&@filter=&@pagesize=50

This issue has the "easy" keyword:

https://bugs.python.org/issue19217

Are "newcomer friendly" and "easy" aimed at somewhat different targets?

Skip


Skip
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7C6WTTBSEYETZDSP6N2JEX2F6NWL5S7E/

[Python-Dev]  New keyword in bpo: `newcomer friendly`

[Mariatta]

 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 to not work on issues tagged with newcomer friendly and leave that
to new contributors.

I’ve added the keyword to Devguide’s Triaging section, with additional
guideline of what can be tagged as newcomer friendly. Typically it should
be straightforward, well-defined issue, and low-risk.

https://devguide.python.org/triaging.html#keywords

Thanks.
ᐧ
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QXWJZWMUXQBPPQBCI6ZA6MN4BUHZ437A/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

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 with patches: 2882 


Issues opened (40)
==

#37633: Py_CompileString and PyParser_SimpleParseString not exported i
https://bugs.python.org/issue37633  opened by pyscripter

#37634: doc: "module" of a warning might be its filename
https://bugs.python.org/issue37634  opened by blueyed

#37635: Using constant for whence arg in seek()
https://bugs.python.org/issue37635  opened by aeros167

#37636: Deprecate slicing and ordering operations on sys.version
https://bugs.python.org/issue37636  opened by ncoghlan

#37637: multiprocessing numpy.ndarray not transmitted properly
https://bugs.python.org/issue37637  opened by 2xB

#37638: Having issues following build instructions
https://bugs.python.org/issue37638  opened by Tianming Zhuang

#37640: telnetlib crash in Python3 while receiving un-printable charac
https://bugs.python.org/issue37640  opened by hoang nguyen

#37641: Embeddable distribution pyc filenames show build machine locat
https://bugs.python.org/issue37641  opened by Bill Collins

#37642: timezone allows no offset from range (23:59, 24:00)
https://bugs.python.org/issue37642  opened by joernheissler

#37645: Replace PyEval_GetFuncName/PyEval_GetFuncDesc
https://bugs.python.org/issue37645  opened by jdemeyer

#37646: eval() in a list comprehension
https://bugs.python.org/issue37646  opened by Grzegorz Krasoń

#37648: Fix minor inconsistency in the order of == operands
https://bugs.python.org/issue37648  opened by serhiy.storchaka

#37649: calculate_init fails to check that EXEC_PREFIX was decoded
https://bugs.python.org/issue37649  opened by orivej

#37650: TemporaryDirectory objects should LOCK_SH to avoid being delet
https://bugs.python.org/issue37650  opened by refi64

#37651: Change of inheritance of asyncio.CancelledError needs document
https://bugs.python.org/issue37651  opened by garyvdm

#37652: Multiprocessing shared_memory ValueError on race with Shareabl
https://bugs.python.org/issue37652  opened by bjs

#37654: 2to3 no-ops on embeddable distribution
https://bugs.python.org/issue37654  opened by Bill Collins

#37657: ERROR: grip 4.5.2 requires docopt>=0.4.0, which is not install
https://bugs.python.org/issue37657  opened by Dima.Tisnek

#37658: In some cases asyncio.wait_for can lead to socket leak.
https://bugs.python.org/issue37658  opened by Nikita Ilyasov

#37659: subprocess.list2cmdline() should not escape wrapping single/do
https://bugs.python.org/issue37659  opened by kejxu

#37660: Drop support for Aspen magic directories in venv's activate sc
https://bugs.python.org/issue37660  opened by brett.cannon

#37661: venv activation scripts erroneously check if __VENV_PROMPT__ i
https://bugs.python.org/issue37661  opened by brett.cannon

#37662: Document venv.EnvBuilder.upgrade_dependencies()
https://bugs.python.org/issue37662  opened by brett.cannon

#37663: Making venv activation script prompts consistent
https://bugs.python.org/issue37663  opened by brett.cannon

#37664: Update bundled pip and setuptools
https://bugs.python.org/issue37664  opened by steve.dower

#37665: threading.TIMEOUT_MAX integer overflow on 32-bit builds with t
https://bugs.python.org/issue37665  opened by Arun Sharma

#37666: urllib.requests.urlopen doesn't support cadata=
https://bugs.python.org/issue37666  opened by gregory.p.smith

#37668: Allow individual test to be specified by "#" or "."
https://bugs.python.org/issue37668  opened by Hasan Diwan

#37669: Make mock_open return per-file content
https://bugs.python.org/issue37669  opened by Anvil

#37673: Tkinter won't create 5000 check boxes, stops at 1309.
https://bugs.python.org/issue37673  opened by Loupz

#37674: Is imp module deprecated or pending deprecation?
https://bugs.python.org/issue37674  opened by Mariatta

#37677: Seg Fault on OSX when multiprocessing
https://bugs.python.org/issue37677  opened by alvis

#37678: Incorrect behaviour for user@password URI pattern in urlparse
https://bugs.python.org/issue37678  opened by Sean.Wang

#37680: distutils appends LDFLAGS environment variable before object f
https://bugs.python.org/issue37680  opened by ozars

#37681: warning: ‘no_sanitize_thread’
https://bugs.python.org/issue37681  opened by shihai1991

#37683: Use importlib.resources in venv
https://bugs.python.org/issue37683  opened by brett.cannon

#37685: Fix equality checks for some types
https://bugs.python.org/issue37685  opened by serhiy.storchaka

#37688: The results from os.path.isdir(...) an Path(...).is_dir() are 
https://bugs.python.org/issue37688  opened by godaygo

#37689: Add Path.is_relative_to()
https://bugs.python.org/issue37689  opened by pitrou

#37690: Simplify linking of shared libraries on the AIX OS

[Python-Dev] Re: Fwd: Re: Comparing dict.values()

[David Mertz]

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, 8:02 AM Greg Ewing 
wrote:

> 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 good ways to express those:
>
> set(d1.values()) == set(d2.values())
>
> list(d1.values()) == list(d2.values())
>
> --
> Greg
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/OHF54Z54D2ERD4L4P72JCJQ5EB3LS5XZ/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CIZSAMTHRV524GZNWRUU6MCXMOUVRJ5E/

[Python-Dev] Re: Comparing dict.values()

[Eric V. Smith]

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 be reflected in the algorithm for
comparing their values()?


Because it's already the case that order doesn't matter when comparing 
dicts and their keys (and presumably items, but I didn't check):


>>> {1:2,2:3} == {2:3,1:2}
True
>>> list({1:2,2:3}.keys())
[1, 2]
>>> list({2:3,1:2}.keys())
[2, 1]
>>> {2:3,1:2}.keys() == {1:2,2:3}.keys()
True
>>>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JOCJL5GWPUVSTMHZ2PSF52FNZJKBXCEN/

[Python-Dev] Re: Comparing dict.values()

[Steven D'Aprano]

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 of values".
>  > 
>  > In this case, they need to be multisets, since 
>  > 
>  > {'a': 1, 'b': 2, 'c': 1}.values() != {'a': 1, 'b': 2, 'c': 2}.values()
> 
> They don't *need* to be multisets.  I would want a comparison of
> values views to be a comparison of images as sets in many cases.

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? And do you really want that to be the default 
behaviour that everyone gets? Remember, too, we don't want the behaviour 
of values views to be too different from the behaviour of dicts, keys 
and items.

I'm not saying that there's no possible scenario where we might want 
that. But it's probably going to be pretty specialised, and probably 
not suitable as the general purpose default behaviour.

Ideally the average Python programmer should say "yeah, that behaviour 
makes sense", without having to follow it up with "... provided you have 
a degree in quantum chromodynamics and the data you are comparing 
represents solitons in a quark-gluon plasma".[1]

Analogy: sometimes I want to do clock arithmetic, where 15 == 3, but 
that doesn't mean that I want int.__eq__ to default to clock arithmetic 
for my (occasional) benefit and everyone else's inconvenience.


> On
> the other hand, if I'm asking if two random variables have the same
> distribution, I would want a comparison of multisets.  And for
> stochastic processes, I'd want a list, not a multiset.  (Sorry for the
> technical jargon, there are probably similar examples from other, more
> realistic domains.)

Comparisons as ordered sequences are easy:

list(d1.values()) == list(d2.values())

Sets are trickier, because the values might not be hashable, but 
depending on your data this could work:

set(d1.values()) == set(d2.values())

I don't think it adds much insight to the problem to discuss all the 
wide variety of specialist comparisons we might want to do in narrow 
circumstances.


[...]
>  > Let's start with the minimal change we have suggested: that two views 
>  > should be considered equal if they both belong to the same dict.
>  > 
>  > assert d.values() == d.values()
>  > 
>  > 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*?
> 
> No, I don't.  Do you think the proposed behavior (extending equality
> to views of the same dict, and only that) is *useful*?

It's *less wrong* than the current behaviour i.e. it gets the comparison 
correct more often, even if it too sometimes returns False for values 
which people would expect to compare equal.





[1] Any relationship between what I said and real physics is purely a 
coincidence :-)




> 
> Steve
> 
> 
> 
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7ZNFSXNMJPLUK7VH7KTCL5K4MPGREYXF/

[Python-Dev] Re: Comparing dict.values()

[Greg Ewing]

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
comparing their values()?

--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OFUKE6AKHQHM7NOLXP2N3UIPX75QRULF/

[Python-Dev] Re: Comparing dict.values()

[Greg Ewing]

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 API:

In the case being considered here, I would argue that attempting
to compare dict.values() results is a symptom of a bug in the
code performing that comparison, or at least a smell suggesting
that the programmer hasn't thought something through properly.

The remedy is to re-write that code to be explicit about what
is really wanted. There is no three-valued logic involved here.

--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FP52QVMJIB6O4DJMZV2NLWC4WIKELRRY/

[Python-Dev] Re: Comparing dict.values()

[Greg Ewing]

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 intended. And we know what the Zen has to say about
guessing.

--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SLVK3KUZ54PO3RFJDNRWI6Q22CAF7KPO/

[Python-Dev] Re: Fwd: Re: Comparing dict.values()

[Greg Ewing]

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 good ways to express those:

   set(d1.values()) == set(d2.values())

   list(d1.values()) == list(d2.values())

--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OHF54Z54D2ERD4L4P72JCJQ5EB3LS5XZ/

[Python-Dev] Re: Comparing dict.values()

[Stephen J. Turnbull]

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': 1, 'b': 2, 'c': 1}.values() != {'a': 1, 'b': 2, 'c': 2}.values()

They don't *need* to be multisets.  I would want a comparison of
values views to be a comparison of images as sets in many cases.  On
the other hand, if I'm asking if two random variables have the same
distribution, I would want a comparison of multisets.  And for
stochastic processes, I'd want a list, not a multiset.  (Sorry for the
technical jargon, there are probably similar examples from other, more
realistic domains.)

So I think I'm in David's camp (from __future__ import
):
we should inherit __eq__, and if we do anything more, we should provide
functions that either do the comparisons correctly (i.e., generalizing
set and multiset to non-hashable values), or very efficiently.

 > Let's start with the minimal change we have suggested: that two views 
 > should be considered equal if they both belong to the same dict.
 > 
 > assert d.values() == d.values()
 > 
 > 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*?

No, I don't.  Do you think the proposed behavior (extending equality
to views of the same dict, and only that) is *useful*?

Steve


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Q54ENOKPCS3XYHK2BPR72462YQT2REEA/

[Python-Dev] Re: Comparing dict.values()

[Steven D'Aprano]

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 these varieties of behaviour? Aside from "change 
nothing" and "raise an exception".

Speaking for myself, its taken a few iterations to nail down *precisely* 
how equality ought to work in detail. 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.

values {1, 2, 2, [], "abc", 3} and {2, 1, "abc", 3, [], 2} are equal 
since each have the same elements and counts:

1 occurs once in both;
2 occurs twice in both;
3 occurs once in both;
[] occurs once in both;
"abc" occurs once in both.

So there's a 1:1 correspondence of elements in one values view to 
elements in the other.

(Ignore the fact that lists are unhashable so cannot be inserted into 
efficient, hash-based Python sets. I'm talking abstract multisets.)

I'll admit it took me a few attempts to get the details right (assuming 
they are right now...), one of my earliest attempts included a fall back 
to compare lists which was a bug.

If there is any other behaviour[1] that makes sense, I haven't seen 
anyone suggest it.



[1] Again, setting aside the current behaviour inherited from object, 
and raising an exception.


-- 
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/36TY6NBE6UG3X7QWWUPMJEBEP57CORIO/

[Python-Dev] Re: Comparing dict.values()

[Greg Ewing]

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 interpreter that it should take some alternative
action. In this case, it will first try the other operand's
__eq__ method, and if that returns NotImplemented as well, it
assumes that the operands are not equal and returns False.

> and is
> it only possible for the `==` operator to return one of `None`, `False`, or
> `True`?

No, it's possible for == to return almost anything (numpy arrays
return an array of booleans, for example). It just happens that
NotImplemented can't be returned, because it has a special
meaning to the interpreter.

--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MHVPVXXMNPQV57LIMDN7VKJIPOH26OQR/

[Python-Dev] Re: Comparing dict.values()

[Steven D'Aprano]

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:
> > 
> >(a.keys() == b.keys()) and (a.values() == b.values)
> 
> I don’t think this invariant holds unless comparison is order dependent.  
> {1:2, 3:4} and {1:4, 3:2} have the same keys and values, but not the same 
> items.  

You are right, they aren't equivalent, that was the wrong term to use.

But not because of dependency on order. They aren't equivalent because 
you can have two dicts where the keys are equal and the values are 
equal, but the items are not:

a = {1: 'a', 2: 'b', 3: 'c'}
b = {1: 'a', 2: 'c', 3: 'b'}

Both dicts have keys {1, 2, 3} and hence equal keys;

both have values {'a', 'b', 'c'} and hence equal values;

but the items are not equal.

So the invariant only goes one way, not both:

(1) items equal implies values (and keys) are also equal;

(2) but values and keys equal doesn't imply items are equal.

But for our purposes, we don't care about case (2) and it doesn't matter 
that it doesn't hold.




-- 
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PA5Z4PL3RZXEBS6WKTLGGGLNBTNNDAXU/

[Python-Dev] Re: Comparing dict.values()

[Steven D'Aprano]

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 following make no sense to you?
> 
> >>> iter(()) == iter(())
> False

Views are not iterators, and the analogy is a poor one.

In their own way, iterators are almost as weird as NANs. (Not *quite* as 
weird, since NANs break reflexivity too: x != x when x is a NAN.) But 
having two iterators which clearly yield the same values in the 
same order compare as unequal is weird.

("Same values in same order" includes the pair of exhausted iterator 
case.)

The behaviour of iterators can be justified, and I'm not going to argue 
that it should be changed. For starters iterators are not *containers*, 
they are conceptually more of a process (yielding values one at a time). 
But we shouldn't emulate iterator behaviour in objects which aren't like 
iterators.

Views are collections. They are sized, containers (support ``in``), 
and iterable:

py> v = {'a': 1, 'b': 2}.values()
py> len(v)
2
py> 2 in v
True
py> list(v)
[1, 2]

and unlike iterators, iterating over a view doesn't exhaust it.

Conceptually, equality of two values view objects should be easy (if we 
don't care about efficiency of implementation). Two views are equal if 
they have the same length, and each value occurs the same number of 
times. Value views don't currently support the .count() method, but if 
they did, we could say two value views a, b were equal if:

len(a) == len(b) and all(a.count(x) == b.count(x) for x in a)

The .count method could be implemented like this:

def count(self, x):
n = 0
for a in self:
if a == x:
n += 1
return n

So there are no conceptual problems in defining equality for value 
views. Putting aside efficiency, this is easy to solve.



-- 
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TSAOXOEXRIE5PXZ2DYR2KKDLTPRCHIHI/

[Python-Dev] Re: Comparing dict.values()

[Steven D'Aprano]

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
> ambiguous.

That's not actually what numpy does:

py> numpy.array([1, 2]) == numpy.array([1, 2])
array([ True,  True], dtype=bool)


In any case, we should not allow numpy's (mis)feature into 
builtins. It might (perhaps...) be okay for third-party objects to break 
the law of excluded middle, and implement de-facto multi-valued logic 
(where an exception == Maybe), but we shouldn't have builtins do that.



-- 
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SSIGTWGWCTLPMTKNPS3ADZ7HBV34NTD5/

[Python-Dev] Re: Comparing dict.values()

[Steven D'Aprano]

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 be undefined.*
> 
> keys, items, and values are not iterators. They are view objects, and 
> keys and items implement the entire set API (in the same sense that 
> range implements the entire sequence API). Values is the odd one out 
> in that it can contain multiple instances of each object, so it can't 
> really be considered as a set.

But it can be considered a multiset.

In plain English, a set can contain duplicates. If I have a set of some 
collectable item (say, trading cards), or a dinner set, they can contain 
duplicates.

We shouldn't make too much of the fact that Python sets collapse 
multiples of a value down to one. If we wanted a multiset, we could get 
one. collections.Counter is already a multiset of sorts.

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, unorderable items if we're willing to 
compromise on efficiency.


> 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 or less Counter(obj1) == Counter(obj2)], 
> and have this fail naturally, throwing e.g. an exception "TypeError: 
> unhashable type: 'list'" if any of the values are unhashable in the 
> same way that trying to perform certain set operations on an items 
> view does.

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 API:


try:
if a == b:
print(True)
else:
print(False)
except Exception:
print(Maybe)  # or undecidable, unknown, mu, etc.


Multi-value logics usually model the complexities of the real world much 
better than boolean logic, but the assumption of boolean logic and the 
law of the excluded middle is too prevalent to mess with in the 
builtins.

http://mathworld.wolfram.com/LawoftheExcludedMiddle.html

https://en.wikipedia.org/wiki/Three-valued_logic



-- 
Steven
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DGVHRP7DSQY43WEDEQBPEMGKYM57WUPU/

[Python-Dev] Re: Comparing dict.values()

[Serhiy Storchaka]

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 value" algorithm [more or less Counter(obj1) == Counter(obj2)], and 
have this fail naturally, throwing e.g. an exception "TypeError: unhashable type: 'list'" 
if any of the values are unhashable in the same way that trying to perform certain set operations 
on an items view does.


-1.  What is the motivation of this?
In this case, I don't think "I found missing parts so I want to
implement it for consistency"
is not enough reason to implement it.

I want a real-world application which requires it.
Without a strong use case, I think the discussion is just wasting time.


Completely agreed.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2KTEL6E3573J7GGUHUBNOD4UOYXJD3DW/

[Python-Dev] Re: Comparing dict.values()

[Kyle Stanley]

> 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 appropriate course of action seems to be updating the 
docs. I have not seen any relevant applications where it would be useful to 
compare the values view between dictionaries, but I agree that the behavior of 
returning `False` might be confusing without any mention of it.

I [opened a PR](https://github.com/python/cpython/pull/14954) which mentions 
this behavior in the relevant documentation, but further explanation of why 
this occurs might be appropriate. I'm not certain as to whether or not further 
explanation is needed in this situation though.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/D6XWQDTNQWXFD5ZKOSM3RTBZEFBXN6KM/