On Tue, Jun 26, 2018 at 8:46 PM Jeroen Demeyer <[email protected]> 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 <[email protected]>
_______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com