[Python-Dev] Policy on refactoring/clean up (original) (raw)
Jeroen Demeyer J.Demeyer at UGent.be
Tue Jun 26 08:13:49 EDT 2018
- Previous message (by thread): [Python-Dev] Policy on refactoring/clean up
- Next message (by thread): [Python-Dev] Policy on refactoring/clean up
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message (by thread): [Python-Dev] Policy on refactoring/clean up
- Next message (by thread): [Python-Dev] Policy on refactoring/clean up
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]