> Part of me agrees with you regarding the generally different tool > lifecycle, but another part says we need these tools in the standard > library or we risk inadvertently breaking the hooks they would still > rely on, even as third party projects. > > I suspect a major factor here relates to the degree of unit test > coverage for these components - for areas that aren't of direct > interest to me, I'll still deal with it if something I do breaks that > code's unit tests, but if the tests don't start failing I'll never > even think to check for an incompatibility. (e.g. I seem to recall > line tracing for with statements and/or generator expressions being > broken for a while before we fixed it) It is at best entertaining to ponder about reasons here; I doubt anything productive can come out of such a discussion. It may be fun posting a message to a ten-year-old issue saying "ACT NOW (you sluggards)", but I question that this will, on average, improve things. Likewise, speculating that tool support is deliberately ignored probably won't improve things (specifically *not* responding to Nick here). On the other hand, posting actual patches that fix actual bugs can make a lot of a difference. Also, having a maintainer who is willing to look into these patches and accept the good ones will make a lot of a difference. Regards, Martin
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