[Python-Dev] Policy on refactoring/clean up
On Tue, Jun 26, 2018 at 8:46 PM Jeroen Demeyer <J.Demeyer at ugent.be> 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
?No, YAGNI is posted by someone and they removed their comment.
My point was:
Moving code around makes:
> - hard to track history.
> - hard to backport patches to old branches.
And I prefer keeping definitions relating to? methods in methodobject.h to
move them to call.h only because they're used/implemented in call.c
> (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) but I
> disagree with that premise: there is a large gray zone between
> "completely useless" and "really needed". My PR falls in that gap of
> "nice to have but we can do without it".
?So I didn't think even it is "nice to have".?
> > You may suggest it as a supplemental PR to PEP 580. Or even a part of
> > it, but since the changes are controversial, better make the
> > refactorings into separate commits so they can be rolled back separately
> > if needed.
> If those refactorings are rejected now, won't they be rejected as part
> of PEP 580 also?
Real need is important than my preference. If it is needed PEP 580, I'm OK.
But I didn't know which part of the PR is required by PEP 580.
INADA Naoki <songofacandy at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...