[Python-Dev] Re: Merging PRs without CLA signed

[Ethan Furman]

On 02/23/2020 08:44 PM, Guido van Rossum wrote:


(What is it with typos anyway? Why do people feel the need to invoke megabytes 
if not gigabytes of internet traffic to correct a word that every reader can 
easily correct in their mind?)


Typos are like skate boarding on fresh asphalt and then hitting a pebble.  Not 
fun.  ;-)

--
~Ethan~
___
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/M7TPAILCOWUILSG3L53L6FQM2YK3V3NH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Kyle Stanley]

> In that case I'm not sure the author ought to get credit for the PR. They
can file a bug pointing out the typo and someone else can submit a fix.

That sounds like a reasonable solution to me; even for more substantial
issues (if signing the CLA is a genuine issue). I think there are a fair
number of individuals out there who just want to fix something and aren't
concerned with attributions or long-term contributions; they just want to
fix the issue for themselves or perhaps for altruistic reasons.

> In the past the people who refused to sign the CLA just had some beef
with the legal system -- that's fine, it's their choice, but we just cannot
accept their contributions: that's our choice.

Yeah, I think that's fair.

> (What is it with typos anyway? Why do people feel the need to invoke
megabytes if not gigabytes of internet traffic to correct a word that every
reader can easily correct in their mind?)

Speaking from personal experience to some degree, my first PR was an
incredibly minimal documentation enhancement:
https://github.com/python/cpython/pull/14069. It's not exactly a typo fix,
but in retrospect, I'd consider it to be about equally impactful. I can't
speak for everyone, but my own motivation was to do something very mildly
helpful just to get a feel for the workflow. It eventually led to
increasingly involved contributions. (:

I think some people might also consider grammatical corrections to be
helpful for bolstering the "professionalism" of the documentation a bit,
but it's hard to say for sure.

> Honestly it seems a rather trivial matter to be so concerned about
fairness. Hopefully a contributor isn't really going to claim "Python Core
Contributor" on their resume based on a typo fix they contributed, and if
they do, I'm not sure whether the CLA requirement is really the key issue
of fairness...

Haha, I had honestly not considered that perspective. But yeah, hopefully
in that case the potential employer would look into the actual contribution
or ask them to link their GitHub, rather than just taking it at face
value...

My concern was mostly just that it might turn some first-contributors away
if they open their first minimal PR, are required to sign the CLA, and then
see that others for similar (or even more involved) PRs didn't have to sign
it. It also has came up enough times that I'd like to have a clear answer
to provide. Perhaps "fairness" could be overstating the issue though.

I was also wondering if there might be any licensing issues for having a
decent volume of total contributions to CPython from individuals without a
CLA signed (even if they're minimal by themselves), but that's likely a
question for the PSF legal team rather than python-dev.

> Write down explicitly that for truly trivial PRs it's at the discretion
of the reviewer?

IMO, that would still be an improvement, because at least then everyone
would have a definitive policy to refer to, even if that policy is "it's up
to the core dev reviewing the PR". I would very much like to know whether
signing the CLA for all PRs is intended to be a concrete policy or if it's
at the discretion of those reviewing the PR. Over the course of my PR
reviews, I've seen quite a number of mixed answers. It's not an absurdly
common issue that is asked on every other PR, but I think it comes up
enough to justify having a more clearly defined policy of some form.

> I believe I've heard that the FSF has a similar policy that states a
maximum number of lines or characters for PRs to be considered possibly
trivial -- but since it's sometimes possible to contribute a truly amazing
speedup that's only a few characters in size, it really ought to be up to
the core dev. Or maybe it should be limited to at most a handful of typo,
grammar or punctuation fixes in docs or comments. (And no splitting it up
into a multiple PRs to duck the limit.)

Both of those also sounds reasonable, and would be aligned with the
existing similar PRs that have been merged without a signed CLA (as far as
I can tell). As mentioned in the OP, I don't have an especially strong
opinion on how it should be handled. More than anything, I'd just like the
policy to be made clear for future PRs so that I can provide an accurate
answer to newer contributors.

On Sun, Feb 23, 2020 at 11:44 PM Guido van Rossum  wrote:

> On Sun, Feb 23, 2020 at 8:11 PM Kyle Stanley  wrote:
>
>> In a recently opened typo fixing PR [1], an issue came up regarding the
>> lack of a signed CLA, where the author specifically mentioned they did not
>> want to sign it for privacy concerns.
>>
>
> In that case I'm not sure the author ought to get credit for the PR. They
> can file a bug pointing out the typo and someone else can submit a fix.
> (This is what Glyph had to do for all his contributions while he was
> employed at Apple.)
>
> While it's *possible* that there are authors there who worry about
> prosecution and don't want their private data exposed to the PSF's database
> of Python contrib

[Python-Dev] Re: Merging PRs without CLA signed

[Kyle Stanley]

> Note that if you open a PR, and _then_ sign the CLA, the label is not
updated (at least, that's what I experienced before I did). So this list is
likely inaccurate.

I believe that I might have seen this happen a few times, but in the
majority cases the label is updated from "CLA not signed" => "CLA signed".
There's a bit of delay (~24-48 hours) from the time you sign the CLA to
when it's updated in the heroku app, so if the PR gets merged during that
time the label might not ever update.

For my own first PR, it was initially not signed when I opened it, and then
the label updated to signed within a couple days after signing the CLA.
This has also been the case in the majority of PRs I've reviewed from
first-time contributors.

On Sun, Feb 23, 2020 at 11:24 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

>
> On 24.02.2020 7:07, Kyle Stanley wrote:
> >
> > For a full list of merged PRs to CPython with a "CLA not signed" label,
> see the following:
> >
> https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr+state%3Amerged+label%3A%22CLA+not+signed%22
> >
> Note that if you open a PR, and _then_ sign the CLA, the label is not
> updated (at least, that's what I experienced before I did). So this
> list is likely inaccurate.
> ___
> 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/IO66YO2SVW55M5KXCAM2P4J7DVMSCK5X/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/F22BOEMMBFZJMVKGVR7YDTR5ZXJKIXAY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Merging PRs without CLA signed

[Guido van Rossum]

On Sun, Feb 23, 2020 at 8:11 PM Kyle Stanley  wrote:

> In a recently opened typo fixing PR [1], an issue came up regarding the
> lack of a signed CLA, where the author specifically mentioned they did not
> want to sign it for privacy concerns.
>

In that case I'm not sure the author ought to get credit for the PR. They
can file a bug pointing out the typo and someone else can submit a fix.
(This is what Glyph had to do for all his contributions while he was
employed at Apple.)

While it's *possible* that there are authors there who worry about
prosecution and don't want their private data exposed to the PSF's database
of Python contributors, I doubt that that's the situation here. Such people
usually have more important things to do than point out typos. In the past
the people who refused to sign the CLA just had some beef with the legal
system -- that's fine, it's their choice, but we just cannot accept their
contributions: that's our choice.

(What is it with typos anyway? Why do people feel the need to invoke
megabytes if not gigabytes of internet traffic to correct a word that every
reader can easily correct in their mind?)


> In the past, I've seen several PRs with similarly minimal [2] changes
> (such as typo fixes, grammar fixes, link fixes, etc) merged without having
> the CLA signed, so it was my assumption that this was acceptable. For a
> full list of merged PRs to CPython with a "CLA not signed" label, see the
> following:
> https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr+state%3Amerged+label%3A%22CLA+not+signed%22
>

Yeah, typically we don't insist on a CLA for trivial fixes -- it's at the
discretion of the core dev reviewing/merging the PR. I actually thought
this was a policy that was written down somewhere, but I don't know where
(maybe somewhere in the devguide?).


> However, I was informed by Pablo Galindo that there are legal issues
> involved with merging *any* PRs without the CLA signed, including typo
> fixes. Personally, I have no strong opinion one way or the other, as I
> don't have an adequate understanding from a legal/licensing perspective.
> But, I think think there's definitely an issue with the lack of consistency
> regarding this policy.
>

I haven't encountered this strong position before. Maybe it's something
Pablo learned from his employer's lawyers? Perhaps more applicable in a
different context?


> *To require a signed CLA for some minimal PRs but not others, solely based
> on who happens to be reviewing the PR, seems rather unfair to potential
> contributors.* From my perspective, the solution seems to be clearly
> defining a more explicit stance on this policy, and having it apply as
> universally as possible to *all* PRs made to CPython.
>

Honestly it seems a rather trivial matter to be so concerned about
fairness. Hopefully a contributor isn't really going to claim "Python Core
Contributor" on their resume based on a typo fix they contributed, and if
they do, I'm not sure whether the CLA requirement is really the key issue
of fairness...


> For example, if the CLA should be required for all PRs, the policy might
> state something like this: "The author of any PR made to the CPython
> repository must have signed the CLA before their PR can be merged. Any PR
> opened by an author that has not signed the CLA can't be merged until it
> has been signed."
>
> OTOH, if it's okay for minimal PRs to not have a signed CLA: "The author
> of any PR made to the CPython repository must have signed the CLA before
> their PR can be merged, except for minimal PRs. Some examples of minimal
> PRs include: ..."
>
> Currently, the policy seems to be learning more towards the former based
> on the devguide [3], where it states "To accept your change we must have
> your formal approval for distributing your work under the PSF license.
> Therefore, you need to sign a contributor agreement which allows the Python
> Software Foundation to license your code for use with Python (you retain
> the copyright)".
>
> However, it seems apparent to me that either this policy isn't explicit
> enough, has a lack of visibility, or simply isn't followed consistently.
> What might be a viable solution to this problem?
>

Write down explicitly that for truly trivial PRs it's at the discretion of
the reviewer? I believe I've heard that the FSF has a similar policy that
states a maximum number of lines or characters for PRs to be considered
possibly trivial -- but since it's sometimes possible to contribute a truly
amazing speedup that's only a few characters in size, it really ought to be
up to the core dev. Or maybe it should be limited to at most a handful of
typo, grammar or punctuation fixes in docs or comments. (And no splitting
it up into a multiple PRs to duck the limit.)


> ---
>
> [1] - https://github.com/python/cpython/pull/18603
>
> [2] - The term "minimal" can be interchanged with "trivial" for the most
> part in the above context, but I tend to prefer the former. IMO, it

[Python-Dev] Re: Merging PRs without CLA signed

[Ivan Pozdeev via Python-Dev]

On 24.02.2020 7:07, Kyle Stanley wrote:


For a full list of merged PRs to CPython with a "CLA not signed" label, see the following: 
https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr+state%3Amerged+label%3A%22CLA+not+signed%22


Note that if you open a PR, and _then_ sign the CLA, the label is not updated (at least, that's what I experienced before I did). So this 
list is likely inaccurate.

___
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/IO66YO2SVW55M5KXCAM2P4J7DVMSCK5X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Merging PRs without CLA signed

[Kyle Stanley]

In a recently opened typo fixing PR [1], an issue came up regarding the
lack of a signed CLA, where the author specifically mentioned they did not
want to sign it for privacy concerns.

In the past, I've seen several PRs with similarly minimal [2] changes (such
as typo fixes, grammar fixes, link fixes, etc) merged without having the
CLA signed, so it was my assumption that this was acceptable. For a full
list of merged PRs to CPython with a "CLA not signed" label, see the
following:
https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr+state%3Amerged+label%3A%22CLA+not+signed%22

However, I was informed by Pablo Galindo that there are legal issues
involved with merging *any* PRs without the CLA signed, including typo
fixes. Personally, I have no strong opinion one way or the other, as I
don't have an adequate understanding from a legal/licensing perspective.
But, I think think there's definitely an issue with the lack of consistency
regarding this policy.

*To require a signed CLA for some minimal PRs but not others, solely based
on who happens to be reviewing the PR, seems rather unfair to potential
contributors.* From my perspective, the solution seems to be clearly
defining a more explicit stance on this policy, and having it apply as
universally as possible to *all* PRs made to CPython.

For example, if the CLA should be required for all PRs, the policy might
state something like this: "The author of any PR made to the CPython
repository must have signed the CLA before their PR can be merged. Any PR
opened by an author that has not signed the CLA can't be merged until it
has been signed."

OTOH, if it's okay for minimal PRs to not have a signed CLA: "The author of
any PR made to the CPython repository must have signed the CLA before their
PR can be merged, except for minimal PRs. Some examples of minimal PRs
include: ..."

Currently, the policy seems to be learning more towards the former based on
the devguide [3], where it states "To accept your change we must have your
formal approval for distributing your work under the PSF license.
Therefore, you need to sign a contributor agreement which allows the Python
Software Foundation to license your code for use with Python (you retain
the copyright)".

However, it seems apparent to me that either this policy isn't explicit
enough, has a lack of visibility, or simply isn't followed consistently.
What might be a viable solution to this problem?

---

[1] - https://github.com/python/cpython/pull/18603

[2] - The term "minimal" can be interchanged with "trivial" for the most
part in the above context, but I tend to prefer the former. IMO, it comes
across as more respectful to the efforts made by the author, as even the
smallest of PRs can require substantial efforts from first-time
contributors that are entirely unfamiliar with the workflow; regardless of
how small the change is.

[3] - https://devguide.python.org/pullrequest/#licensing

Regards,
Kyle Stanley
___
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/LH6WQI7GGS6URLXOGYGAPJIOXKGVIX2Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

[Guido van Rossum]

On Sat, Feb 22, 2020 at 10:09 PM Steven D'Aprano 
wrote:

> On Tue, Feb 18, 2020 at 05:35:38PM -, Brandt Bucher wrote:
> > > I am accepting this PEP. Congratulations Steven and Brandt!
> >
> > Thank you for your guidance, especially the suggestions late last
> > year. And thanks Steven for taking me on as a co-author and shaping
> > the bulk of the proposal.
>
> Thank you Guido, and thank you Brandt for volunteering to do the heavy
> lifting with the proof of concept code etc. I never could have done this
> without you.
>

You're welcome. Thanks for providing the initial impetus to make this
happen! And thanks a lot to Brandt for his implementation work.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(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/DENDBYA4JREJ5P2NS66BCWEWICY3TDMO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

[Guido van Rossum]

On Sat, Feb 22, 2020 at 4:45 PM Brandt Bucher 
wrote:

> [quoting Nick]
> > collections.Mapping and collections.MutableMapping could provide
> concrete method implementations that make subclasses behave in a way that's
> similar to built-in dicts
>
> Hm, haven't thought too much about this (I don't have much experience with
> the ABCs). Would they return dicts, or call the self.copy and self.update
> methods?
>
> Those are just hypothetical questions for now; I don't necessarily want to
> dig too far into that discussion again. But I agree that it's definitely
> worth considering. ;)
>

Mapping and MutableMapping don't have copy() methods -- these are
intentionally narrower interfaces than dict. I think we should leave them
alone. The PEP does *not* propose to add `|` to Mapping, and that's
intentional. Because of this I think we should also not add `|=` to
MutableMapping, even though it does have an update() method. Adding it
(even with a default implementation) could cause discrepancies to virtual
subclasses registered with MutableMapping.register(C).

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(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/ZYS4QSU4NIISYCYUZO2QZIVSNC5FYC2A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 584: Add Union Operators To dict

[Guido van Rossum]

On Sat, Feb 22, 2020 at 11:28 AM Brandt Bucher 
wrote:

> Just to follow up on this, here are the subclasses I've found.
>
> Should be updated:
> - collections.OrderedDict
> - collections.defaultdict
>

SGTM.

- http.cookies.BaseCookie
> - http.cookies.Morsel
> - http.cookies.SimpleCookie
>

Are these three cookie classes sufficiently popular that we need to support
`|` on them?


> Don’t think so:
> - typing.TypedDict
>

Agreed, since at runtime this doesn't exist -- calling TypedDict(...)
returns a plain dict instance.


> Already defines the operator:
> - collections.Counter
>
> Not Public (or at least not documented):
> - _strptime.TimeRE
> - builtins.StgDict (this one's only available internally in _ctypes).
> - email._encoded_words._QByteMap
> - enum._EnumDict
> - logging.config.ConvertingDict
> - multiprocessing.pool._PoolCache
> - urllib.parse.Quoter
>

Yeah, let's stay away from these.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(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/3MXTZFR7NOZMXFMVKJLA4VMVJ6QVHCA5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 585: Type Hinting Generics In Standard Collections

[Batuhan Taskaya]

This issue might be useful about it: https://bugs.python.org/issue39019

On Sun, Feb 23, 2020 at 2:12 PM Ethan Smith  wrote:
>
> While working on the implementation with Guido I made a list of things that 
> inherit from typing.Generic in typeshed that haven't been listed/implemented 
> yet.
>
> https://github.com/gvanrossum/cpython/pull/1#issuecomment-582781121
>
>
>
> On Sat, Feb 22, 2020, 3:50 PM Nick Coghlan  wrote:
>>
>> This looks like a nice usability improvement to me.
>>
>> My only suggestion would be that types.MappingProxyType be included on the 
>> list of types to be updated.
>>
>> Cheers,
>> Nick.
>> ___
>> 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/EYU3VDK7T4OVT7MXM5OWOPFA4YKWXVDE/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> 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/Z47AGWUR5ZVQQ7GEEFQYPE5HBCUMEL44/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
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/SMSLIJOYCEFN6TEWHFX7ELO5FWKJEGYK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 585: Type Hinting Generics In Standard Collections

[Ethan Smith]

While working on the implementation with Guido I made a list of things that
inherit from typing.Generic in typeshed that haven't been
listed/implemented yet.

https://github.com/gvanrossum/cpython/pull/1#issuecomment-582781121



On Sat, Feb 22, 2020, 3:50 PM Nick Coghlan  wrote:

> This looks like a nice usability improvement to me.
>
> My only suggestion would be that types.MappingProxyType be included on the
> list of types to be updated.
>
> Cheers,
> Nick.
> ___
> 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/EYU3VDK7T4OVT7MXM5OWOPFA4YKWXVDE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/Z47AGWUR5ZVQQ7GEEFQYPE5HBCUMEL44/
Code of Conduct: http://python.org/psf/codeofconduct/