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

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

[Python-Dev] Re: [python-committers] [RELEASE] Python 3.8.0b3 is now available for testing

I have updated the official docker images with 3.8b3: https://gitlab.com/python-devs/ci-images/tree/master -Barry > On Jul 29, 2019, at 14:48, Łukasz Langa wrote: > > Signed PGP part > This time without delays, I present you Python 3.8.0b3: > >

[Python-Dev] [RELEASE] Python 3.8.0b3 is now available for testing

This time without delays, I present you Python 3.8.0b3: https://www.python.org/downloads/release/python-380b3/ This release is the third of four planned beta release previews. Beta release previews are intended to give the wider

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

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() ==

[Python-Dev] Re: typing: how to use names in result-tuples?

Can't you use the proper inline form of NamedTuple? def f() -> typing.NamedTuple("__f", [("x", int), ("y", int)]): ... seems to work. On Mon, Jul 29, 2019 at 8:26 AM Christian Tismer wrote: > Hi friends, > > I am meanwhile the PySide maintainer at The Qt Company, > and we are trying to

[Python-Dev] typing: how to use names in result-tuples?

Hi friends, I am meanwhile the PySide maintainer at The Qt Company, and we are trying to make the mapping from Qt functions to Python functions as comparable as possible. One problem are primitive pointer variables: In Qt, it is natural to use "sometype *varname" to make a mutable variable. In

[Python-Dev] Re: [core-workflow] Re: Re: %G%@ New keyword in bpo: `newcomer friendly`

Stephen J. Turnbull wrote: > In general, it's not obvious to me how much extra burden we want to > put on triagers. This tag has basically the same problems that "easy" > does, except that it deters experienced developers from snatching up > easy issues. I think we should see how this works out

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

IMHO such label should be removed at some point from an issue when there is too much disagreement about the issue and/or the proposed solutions. You can find 5 years old "easy" issue with 30+ messages. Such issue even scares me who is used to old bugs. Such issue is no longer "newcomer friendly".

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

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.

[Python-Dev] Re: [core-workflow] Re: Re: %G%@ New keyword in bpo: `newcomer friendly`

Guido van Rossum writes: > And in part because we will have specific guidelines (to be nailed > down more precisely in the dev guide) about how to ensure that an > issue is newcomer friendly. I don't have the thread handy but it's > something about having a clear (to newcomers, not just to