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.
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