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

[Stephen J. Turnbull]

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 core
 > devs) description, without too much jargon, and some (but not too
 > many) hints for a solution.

I don't think it's a good idea to put too much structure on this.
Specifically, some newcomers are new programmers, and some are new to
open source processes.  Even if editing the code is really easy, such
an issue is good "process" practice.

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 in practice
before reducing the number of issues tagged and at the same time
increasing burden.

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/5N2SSLQBNCFHQXG2NTMGCNURUJ3D26GV/

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

[Stephen J. Turnbull]

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.  We have views into a dictionary.  A
dictionary is one way to implement a function, and it's often
interesting to know what the image of a function is.  I would guess
this is one reason why set(d.view()) came up early in the discussion.
I hardly think that the range of values in a dict is something that
Python programmers would need a PhD to understand, at least not if you
present it as "set(d.values())", and optionally "but works if values
aren't hashable".

I'm -1 on any of the possibilities proposed to be anointed as "==" for
dict.values without data on how often they are used in practice, and
how often each is used in inner loops.  All are easy to spell since
dict.values is iterable (if you accept the restriction for set that
all dict values be hashable).

I would argue that if anything is to be implemented in built ins, it
should be the set comparison, since that is the only one that doesn't
have a simple spelling for generic dicts.  (That doesn't mean I think
it should be "==".)

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

I already knew you cared that the minute hand of a stopped clock is
right 24 times a day.  I don't, and that's not what I asked.

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/NX2FFQ6Y5DCI7EQMRXN7TXQ7V5VNK2YG/

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

[Victor Stinner]

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

Victor

Le dim. 28 juil. 2019 à 22:37, Antoine Pitrou  a écrit :
>
> On Fri, 26 Jul 2019 19:09:35 -0700
> Guido van Rossum  wrote:
> > 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.
>
> But how do we know that the same mistake won't be done again? :-)
>
> Regards
>
> Antoine.
>
> ___
> 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/IWJLWGOB25QVLOBL6J2L2FZQXJOKESJJ/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/D55GVS7OHBQCXGHZU37BEHEIQFXOAIAD/

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

[Kyle Stanley]

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 in practice
> before reducing the number of issues tagged and at the same time
> increasing burden.
> Steve

That's why I think we should continue to use the "easy" tag to
describe easier issues targeted towards those with some basic
familiarity, but with less experience and "newcomer friendly" to
be the easier version of "easy". Newcomer friendly should
optimally be reserved for incredibly quick/trivial fixes that serve
as an introduction to the process more than an actual issue
which needs to be addressed.
___
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/ILMPXTBFHIHCSC4ZDNDR4GNGKSSFVD24/

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

[Christian Tismer]

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, you have to turn such a thing
into a result-tuple. Example:

void QPrinter::getPageMargins(qreal *left, qreal *top, \
qreal *right, qreal *bottom, QPrinter::Unit unit) const

(meanwhile deprecated, but a good example)

is mapped to the Python signature

def getPageMargins(self, \
unit: PySide2.QtPrintSupport.QPrinter.Unit) \
-> typing.Tuple[float, float, float, float]: ...

NOW my question:


I would like to retain the variable names in Python!
The first idea is to use typing.NamedTuple, but I get the impression
that this would be too much, because I would not only need to create
an extra named tuple definition for every set of names, but also
invent a name for that named tuple.

What I would like to have is something that looks like

def getPageMargins(self, \
unit: PySide2.QtPrintSupport.QPrinter.Unit) \
-> typing.NamedTuple[left: float, top: float, \
 right:float, bottom:float]: ...

but that is obviously not a named tuple.
Possible would be to derive a name from the function, so maybe
a definition could be used like

class PageMargingResult(NamedTuple):
left: float
top: float
right: float
bottom: float

but then I would have some opaque PageMargingResult type. This would
work, but as said, this is a bit too much, since I only
wanted something like a tuple with names.

What do you suggest to do here? Something what I am missing?

Cheers -- Chris
-- 
Christian Tismer :^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : https://github.com/PySide
14482 Potsdam: GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



___
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/YGZELVWRGXZ5BTD4ZMATQT7IRAZVQSHR/

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

[Guido van Rossum]

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 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, you have to turn such a thing
> into a result-tuple. Example:
>
> void QPrinter::getPageMargins(qreal *left, qreal *top, \
> qreal *right, qreal *bottom, QPrinter::Unit unit) const
>
> (meanwhile deprecated, but a good example)
>
> is mapped to the Python signature
>
> def getPageMargins(self, \
> unit: PySide2.QtPrintSupport.QPrinter.Unit) \
> -> typing.Tuple[float, float, float, float]: ...
>
> NOW my question:
> 
>
> I would like to retain the variable names in Python!
> The first idea is to use typing.NamedTuple, but I get the impression
> that this would be too much, because I would not only need to create
> an extra named tuple definition for every set of names, but also
> invent a name for that named tuple.
>
> What I would like to have is something that looks like
>
> def getPageMargins(self, \
> unit: PySide2.QtPrintSupport.QPrinter.Unit) \
> -> typing.NamedTuple[left: float, top: float, \
>  right:float, bottom:float]: ...
>
> but that is obviously not a named tuple.
> Possible would be to derive a name from the function, so maybe
> a definition could be used like
>
> class PageMargingResult(NamedTuple):
> left: float
> top: float
> right: float
> bottom: float
>
> but then I would have some opaque PageMargingResult type. This would
> work, but as said, this is a bit too much, since I only
> wanted something like a tuple with names.
>
> What do you suggest to do here? Something what I am missing?
>
> Cheers -- Chris
> --
> Christian Tismer :^)   tis...@stackless.com
> Software Consulting  : http://www.stackless.com/
> Karl-Liebknecht-Str. 121 : https://github.com/PySide
> 14482 Potsdam: GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
>
>
>
> ___
> 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/YGZELVWRGXZ5BTD4ZMATQT7IRAZVQSHR/
>


-- 
--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/LSNP3DUXGP3SD3BVMSWROAGPC67T26XE/

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

[Stefan Behnel]

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.items()
> ```
> 
> but `d.values() == d.values()` does not return the expected
> results. It always returns `False`. The symmetry is a bit off.
> 
> In the bug trackers[0] and the Github PR[1], I was asked
> to raise the issue on the python-dev mailing list to find
> a consensus on what comparing `.values()` should do.
> 
> I'd argue that Python should compare the values as expected here,
> or if we don't want to encourage that behaviour, maybe we should
> consider raising an exception. 
> Returning just `False` seems a bit misleading.
> 
> What are your thoughts on the issue?

FWIW, after reading most of this thread, I do not like the idea of raising
an exception for an innocent comparison. Just think of a list of arbitrary
objects, including a dict values view for some reason, and you're looking
for the right object in the list. Maybe in some kind of generic tool,
decorator, iter-helper, or whatever, something that has to deal with
arbitrary objects provided by random users, which uses "in" instead of a
loop with "is" comparisons.

I also kind-of like the idea of having

d.values() == d.values()

return True and otherwise let the comparison return False for everything
else. This seems to be the only reasonable behaviour that might(!) have a
use case, maybe in the same line as the argument above. I can't really see
a reason for implementing anything more than that.

Stefan
___
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/CGRTXKDHS7GBBZY5GQ6ZM2FAVHPHJBAQ/

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

[Łukasz Langa]

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 community the opportunity to test new 
features and bug fixes and to prepare their projects to support the new feature 
release. The next pre-release of Python 3.8 will be 3.8.0b4, the last beta 
release, currently scheduled for 2019-08-26.

Call to action

We strongly encourage maintainers of third-party Python projects to test with 
3.8 during the beta phase and report issues found to the Python bug tracker 
 as soon as possible. While the release is planned to 
be feature complete entering the beta phase, it is possible that features may 
be modified or, in rare cases, deleted up until the start of the release 
candidate phase (2019-09-30). Our goal is have no ABI changes after beta 3 and 
no code changes after 3.8.0rc1, the release candidate. To achieve that, it will 
be extremely important to get as much exposure for 3.8 as possible during the 
beta phase.

Please keep in mind that this is a preview release and its use is not 
recommended for production environments.

Last beta coming

Beta 4 can only be released if all “Release blocker” and “Deferred blocker” 
issues on bugs.python.org  for 3.8.0 are resolved. 
Please prioritize those for the next four weeks.

Acknowledgements

Thanks to our binary builders, Ned and Steve, who were very quick today to get 
the macOS and Windows installers ready. The Windows story in particular got 
pretty magical, it’s now really fully automatic end-to-end.

Thanks to Victor for vastly improving the reliability of multiprocessing tests 
since Beta 2.

Thanks to Pablo for keeping the buildbots green.


- Ł


signature.asc
Description: Message signed with OpenPGP
___
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/BCIHRB5N6AKPCBVO4TQYSYSPOBMV3GXL/

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

[Barry Warsaw]

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:
> 
> https://www.python.org/downloads/release/python-380b3/



signature.asc
Description: Message signed with OpenPGP
___
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/2T7AXF4D7KIQML5QDNBX7I5KQWJOPKE3/

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

[Random832]

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

And think of what we could do if we were willing to compromise on immutability 
of hashable objects (Java does, in general, make the opposite decision there)
___
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/JJDKUFGILK2ESMUZULDB4I2VJFX3VQRC/