Martin v. Löwis <martin at v.loewis.de> wrote: > > If a library is well maintained then there seems to be little point in > > moving it into the standard library as it may actually be harder to > > maintain > > It depends. For quickly evolving libraries, it might be harder to > maintain them in the core, as you can't release as quickly as you > desire. In other cases, it simplifies maintenance: whenever a > systematic API change is added, all standard library modules get > typically updated by whoever makes the systematic change. That is > more productive than having each individual maintainer to figure out > what to change in response. This is a complicated issue. But two sub-threads seem to be about (1) modules dependent (or wrapping) a large, complicated third-party library under active development, and (2) hard-to-routinely-test modules, like imaplib. Bill
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