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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4