On 1/31/2022 7:31 PM, Nikita Sobolev wrote:
Hi, my name is Nikita and I think that I am the person behind these spammy PRs.
Link: https://github.com/python/cpython/pulls/sobolevn
Nikita, I don't know if the OP was responding only to your PRs or
others, but I other people have seen truly
Hi, my name is Nikita and I think that I am the person behind these spammy PRs.
Link: https://github.com/python/cpython/pulls/sobolevn
First of all, Lrupert, sorry for all the noise and inconvenience I caused to
you personally and to other community members! This totally was **not** my
If you feel bad impression, sorry about that.
The mentee who cc me is under mentoring period. Since tracking all of
mentee’s activity is impossible, I requested him to cc me.
This was for checking his labeling is valid or not.
Warm regards
Dong-hee
2022년 2월 1일 (화) 오전 5:35, Lrupert via Python-Dev
On Mon, 31 Jan 2022 at 23:29, Greg Ewing
wrote:
> Or they may just feel that it's better to organise their changes into
> a number of small, independent commits rather than one large one. I
> wouldn't be too quick to jump to conclusions about people's motives
> here.
I've found that highly
On 1/02/22 5:47 am, Lrupert via Python-Dev wrote:
This gives
a bad impression to others about their intentions (constant contribution
of trivial / low quality stuff with little-to-no-gain to achieve a
higher number of commits, since it is a visible metric).
Or they may just feel that it's
On 1/31/22 8:47 AM, Lrupert via Python-Dev wrote:
> This gives a bad impression to others about their intentions (constant
contribution of trivial
> / low quality stuff with little-to-no-gain to achieve a higher number of
commits, since it is
> a visible metric).
Two of us have already
Okay, now you might as well state which person you are talking about. Who
says their mentor hasn't encouraged them to do this?
On Mon, Jan 31, 2022 at 12:32 PM Lrupert via Python-Dev <
python-dev@python.org> wrote:
> > Gaming the system doesn't end up working well in the end anyway. The
> first
> Gaming the system doesn't end up working well in the end anyway. The first
> time the gamers try to get a job interview and can't explain how they'd do a
> code review—something GitHub says they've done hundreds or thousands of
> times—the whole thing will fail.
Observably, it feels like
Ah, now I see the section on GitHub user home pages. Honestly if employers
just take a glance at that they get what they deserve. I don't want to
worry about this, there are enough real problems.
On Mon, Jan 31, 2022 at 8:48 AM Brian Curtin wrote:
> I was using points in a more generic sense,
I was using points in a more generic sense, making your "contribution
activity overview" look nicer—I wasn't sure if "points" was an actual thing
or not, so maybe I'm speaking out of turn. Mine shows 70% of my actions are
code review, then issues, commits, and PRs are 10% each.
On Mon, Jan 31,
Where does it say that a review gives you points? The GitHub blog post I
saw about the subject only mentions commits.
On Mon, Jan 31, 2022 at 8:16 AM Brian Curtin wrote:
> On Sun, Jan 30, 2022 at 8:42 AM Mats Wichmann wrote:
>
>> On 1/30/22 04:45, Inada Naoki wrote:
>> > On Sun, Jan 30, 2022
On Sun, Jan 30, 2022 at 8:42 AM Mats Wichmann wrote:
> On 1/30/22 04:45, Inada Naoki wrote:
> > On Sun, Jan 30, 2022 at 7:37 PM Irit Katriel
> wrote:
>
> > Some people may do "approval without review" to make their "Profile"
> > page richer, because GitHub counts it as a contribution.
> >
@Lrupert
> - Add coverage to X (tens of them, as separate PRs)
I think I know the PRs you're referring to. For the record, some of the PRs
tested hairy code paths in the module I maintain. I would have less confidence
backporting bugfixes touching that code if we didn't have those tests (the
On Mon, Jan 31, 2022 at 4:03 PM Petr Viktorin wrote:
> > If we change the stable ABI, I would prefer to fix multiple issues at
> > once. Examples:
> >
> > * No longer return borrowed references (ex: PyDict_GetItem is part of
> > the stable ABI) and no longer steal references (ex:
> >
On 31. 01. 22 15:40, Victor Stinner wrote:
On Mon, Jan 31, 2022 at 1:48 PM Petr Viktorin wrote:
(* we could also break the stable ABI, and we could even do it
reasonably safely over a long period of time, but that's a whole
different discussion.)
IMO the stable ABI must be change in the
On 31. 01. 22 15:30, Victor Stinner wrote:
On Mon, Jan 31, 2022 at 2:31 PM Petr Viktorin wrote:
PEP: 674
Title: Disallow using macros as l-value
The current PEP is named "Disallow using Py_TYPE() and Py_SIZE() macros
as l-values", which is misleading: it proposes to change 65 macros.
On Mon, Jan 31, 2022 at 1:48 PM Petr Viktorin wrote:
> (* we could also break the stable ABI, and we could even do it
> reasonably safely over a long period of time, but that's a whole
> different discussion.)
IMO the stable ABI must be change in the long term, it still leaks too
many
On Mon, Jan 31, 2022 at 2:31 PM Petr Viktorin wrote:
> > PEP: 674
> > Title: Disallow using macros as l-value
>
> The current PEP is named "Disallow using Py_TYPE() and Py_SIZE() macros
> as l-values", which is misleading: it proposes to change 65 macros.
Right, I made changes since I posted the
On 18. 01. 22 9:30, Victor Stinner wrote:
Hi,
I made the following changes to the PEP since the version 1 (November 30):
* Elaborate the HPy section and add a new "Relationship with the HPy
project" section
* Elaborate which projects are impacted and which changes are needed
* Remove the PyPy
On 28. 01. 22 16:04, Victor Stinner wrote:
Hi,
There is a reason why I'm bothering C extensions maintainers and
Python core developers with my incompatible C API changes since Python
3.8. Let me share my plan with you :-)
In 2009 (Python 3.2), Martin v. Löwis did an amazing job with the PEP
On 31/01/2022 5:23 am, Gregory P. Smith wrote:
-cc: python-steering-council
On Fri, Mar 5, 2021 at 4:26 PM Guido van Rossum mailto:gu...@python.org>> wrote:
On Fri, Mar 5, 2021 at 11:11 AM Brett Cannon mailto:br...@python.org>> wrote:
Speaking for myself ...
Ditto ...
21 matches
Mail list logo
