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 (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".
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?
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 (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".
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?
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 with. Thus any "would be nice to have" tinkerings are essentially a waste of time and possibly a degradation, too: you'll very likely have to change them again when the real need arises -- while having to live with any drawbacks in the meantime. So, if you suggest those changes together with the PEP 580 PR, they will be reviewed through the prism of the new codebase and its needs, which are different from the current codebase and its needs.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru
-- Regards, Ivan
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 still useful to have.
Inada pointed me to YAGNI (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".
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?
This is exactly what that the YAGNI principle is about, and Inada was right to point to it.
Strike this part out since he didn't actually say that as it turned out.
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 with. Thus any "would be nice to have" tinkerings are essentially a waste of time and possibly a degradation, too: you'll very likely have to change them again when the real need arises -- while having to live with any drawbacks in the meantime.
So, if you suggest those changes together with the PEP 580 PR, they will be reviewed through the prism of the new codebase and its needs, which are different from the current codebase and its needs.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru
-- Regards, Ivan
On Tue, Jun 26, 2018 at 8:46 PM Jeroen Demeyer <J.Demeyer@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@gmail.com>
On 26.06.2018 14:54, INADA Naoki wrote:
On Tue, Jun 26, 2018 at 8:46 PM Jeroen Demeyer <J.Demeyer@ugent.be <mailto:J.Demeyer@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.
Yes, that was me instead. I posted it and then changed my mind. Apparently, notifications were sent nonetheless. I didn't watch the thread and kinda assumed that you pointed that out, too. (Just to put everything straight and not make anyone suspect I'm trying to pull the wool over anyone's eyes here.)
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@gmail.com <mailto:songofacandy@gmail.com>>
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru
-- Regards, Ivan
participants (3)
-
INADA Naoki -
Ivan Pozdeev -
Jeroen Demeyer