[Python-Dev] Policy on refactoring/clean up

[Petr Viktorin]

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.