Nick Coghlan writes: > People need to remember there's another half to this equation: the > core dev side. Why? There's nothing about it in the PEP.<wink/> > The reason *regex* specifically isn't in the stdlib already is > largely due to (perhaps excessive) concerns about the potential > maintenance burden. But then giving regex as an example seems to contradict the PEP: "The only difference between preview APIs and the rest of the standard library is that preview APIs are explicitly exempted from the usual backward compatibility guarantees," "in principle, most modules in the __preview__ package should eventually graduate to the stable standard library," and "whenever the Python core development team decides that a new module should be included into the standard library, but isn't sure about whether the module's API is optimal". True, there were a few bits spilled on the possibility of being "without sufficient developer support to maintain it," but I read that as a risk that is basically a consequence of instability of the API. The rationale is entirely focused on API instability, and a focus on API instability is certainly the reason for calling it "__preview__" rather than "__experimental__". I don't have an opinion on whether this is an argument for rejecting the PEP or for rewriting it (specifically, seriously beefing up the "after trying it, maybe we won't want to maintain it" rationale). I also think that if "we need to try it to decide if the maintenance burden is acceptable" is a rationale, the name "__experimental__" should be seriously reconsidered as more accurately reflecting the intended content of the package.
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