osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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.
>
>  https://github.com/python/cpython/pull/7909#issuecomment-400219905

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.

Regards,

-- 
INADA Naoki  <songofacandy at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180626/13b62b45/attachment.html>