Re: [Python-Dev] Policy on refactoring/clean up

In itself, the code clean up you have done is a good thing in the sense that you re-organized things and in my understanding, they look good now. In some of the teams I've been granted to work, there was a rule stating that whenever a dev would work on an enhancement/bugfix, he would create a

Re: [Python-Dev] Policy on refactoring/clean up

On Wed, Jun 27, 2018 at 2:27 PM Jeroen Demeyer wrote: > On 2018-06-27 00:02, Guido van Rossum wrote: > > And TBH a desire to refactor a lot of code is often a sign of a > > relatively new contributor who hasn't learned their way around the code > > yet, so they tend to want to make the code

Re: [Python-Dev] Policy on refactoring/clean up

On 2018-06-27 00:02, Guido van Rossum wrote: And TBH a desire to refactor a lot of code is often a sign of a relatively new contributor who hasn't learned their way around the code yet, so they tend to want to make the code follow their understanding rather than letting their understanding

Re: [Python-Dev] Policy on refactoring/clean up

I know there was a big follow-up already, but I'd like to point out that (while clearly not everyone feels the same) I am personally inclined to set the bar pretty high for refactoring that don't add functionality. It makes crawling through history using e.g. git blame harder, since the person who

Re: [Python-Dev] Policy on refactoring/clean up

On 26.06.2018 14:54, Ivan Pozdeev via Python-Dev wrote: On 26.06.2018 14:43, Jeroen Demeyer wrote: On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote: AFAICS, your PR is not a strict improvement What does "strict improvement" even mean? Many changes are not strict improvements, but

Re: [Python-Dev] Policy on refactoring/clean up

On 06/26/18 14:13, Jeroen Demeyer wrote: On 2018-06-26 13:54, Ivan Pozdeev via Python-Dev wrote: This is exactly what that the YAGNI principle is about, and Inada was right to point to it. Until you have an immediate practical need for something, you don't really know the shape and form for it

Re: [Python-Dev] Policy on refactoring/clean up

On 2018-06-26 13:54, INADA Naoki wrote: Real need is important than my preference. If it is needed PEP 580, I'm OK. Of course it's not needed. I never claimed that it was. I think it's *nice to have* right now and slightly more *nice to have* when changes/additions are made to call.c in the

Re: [Python-Dev] Policy on refactoring/clean up

On 2018-06-26 13:54, Ivan Pozdeev via Python-Dev wrote: This is exactly what that the YAGNI principle is about, and Inada was right to point to it. Until you have an immediate practical need for something, you don't really know the shape and form for it that you will be the most comfortable

Re: [Python-Dev] Policy on refactoring/clean up

On Tue, 26 Jun 2018 11:00:48 +0200 Jeroen Demeyer wrote: > Hello, > > On https://github.com/python/cpython/pull/7909 I encountered friction > for a PR which I expected to be uncontroversial: it just moves some code > without changing any functionality. > > So basically my question is: is

Re: [Python-Dev] Policy on refactoring/clean up

On 26.06.2018 14:54, INADA Naoki wrote: On Tue, Jun 26, 2018 at 8:46 PM Jeroen Demeyer > wrote: On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote: > AFAICS, your PR is not a strict improvement What does "strict improvement" even mean? Many changes

Re: [Python-Dev] Policy on refactoring/clean up

On 2018-06-26 13:54, INADA Naoki wrote: ​No, YAGNI is posted by someone and they removed their comment. Sorry for that, I misunderstood the email that GitHub sent me. ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Policy on refactoring/clean up

On Tue, Jun 26, 2018 at 8:46 PM Jeroen Demeyer wrote: > On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote: > > AFAICS, your PR is not a strict improvement > > What does "strict improvement" even mean? Many changes are not strict > improvements, but still useful to have. > > Inada pointed me

Re: [Python-Dev] Policy on refactoring/clean up

On 26.06.2018 14:43, Jeroen Demeyer wrote: On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote: AFAICS, your PR is not a strict improvement What does "strict improvement" even mean? Many changes are not strict improvements, but still useful to have. Inada pointed me to YAGNI

Re: [Python-Dev] Policy on refactoring/clean up

On 2018-06-26 13:11, Ivan Pozdeev via Python-Dev wrote: AFAICS, your PR is not a strict improvement What does "strict improvement" even mean? Many changes are not strict improvements, but still useful to have. Inada pointed me to YAGNI

Re: [Python-Dev] Policy on refactoring/clean up

Hi, I created call.c when I worked on optimizations. I saw that performances depend on the code locality and that compilers are more eager to inline code when it's in the same file. Moreover, call.c now contains some private functions like function_code_fastcall() or _PyObject_CallFunctionVa()

Re: [Python-Dev] Policy on refactoring/clean up

On 26.06.2018 12:00, Jeroen Demeyer wrote: Hello, On https://github.com/python/cpython/pull/7909 I encountered friction for a PR which I expected to be uncontroversial: it just moves some code without changing any functionality. So basically my question is: is there some CPython policy

Re: [Python-Dev] Policy on refactoring/clean up

26.06.18 12:11, INADA Naoki пише: FYI, I don't against general refactoring, when I agree it's really make code cleaner, readable. I against your PR because I didn't feel it really make code cleaner, readable. I already commented about it on the PR.

Re: [Python-Dev] Policy on refactoring/clean up

FYI, I don't against general refactoring, when I agree it's really make code cleaner, readable. I against your PR because I didn't feel it really make code cleaner, readable. I already commented about it on the PR. https://github.com/python/cpython/pull/7909#issuecomment-400219905 So it's not

[Python-Dev] Policy on refactoring/clean up

Hello, On https://github.com/python/cpython/pull/7909 I encountered friction for a PR which I expected to be uncontroversial: it just moves some code without changing any functionality. So basically my question is: is there some CPython policy *against* refactoring code to make it easier to