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 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.
It is important to clarify that this is exactly what I did. I *have* an implementation of PEP 580 and it's based on that PR 7909. I just think that this PR makes sense independently of whether PEP 580 will be accepted.
So, if you suggest those changes together with the PEP 580 PR
That sounds like a bad idea because that would be mixing two issues in one PR. If I want to increase my chances of getting PEP 580 and its implementation accepted, I shouldn't bring in unrelated changes. To put it in a different perspective: if somebody else would make a PR to one of my projects doing a refactoring and adding new features, I would ask them to split it 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 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.
It is important to clarify that this is exactly what I did. I *have* an implementation of PEP 580 and it's based on that PR 7909.
I just think that this PR makes sense independently of whether PEP 580 will be accepted.
So, if you suggest those changes together with the PEP 580 PR
That sounds like a bad idea because that would be mixing two issues in one PR. If I want to increase my chances of getting PEP 580 and its implementation accepted, I shouldn't bring in unrelated changes.
To put it in a different perspective: if somebody else would make a PR to one of my projects doing a refactoring and adding new features, I would ask them to split it up.
Actually, that's exactly what we *did* ask Jeroen with his earlier proposal for PEP 575, where the implementation ended up being quite big. Split the changes to make it more manageable. Unfortunately I haven't had time to study this PR yet (work is taking all my time lately), but I trust that Jeroen will propose actual improvements on top of the clean-up.
participants (2)
-
Jeroen Demeyer -
Petr Viktorin