>> Prepare for a ten-year period of acceptance - so it >> would be good to be sure that no further additions are desired within >> the next ten years before seeking approval for the PEP. > > However, this point I really don't agree with. The packaging ecosystem > is currently evolving outside the standard library, but the > standardisation process for the data interchange formats still falls > under the authority of python-dev and the PEP process. Maybe I misphrased. By "accepted" I meant "widely implemented". From the day this gets published until it is really usable, I still believe 10 years is realistic. For example, setuptools doesn't implement Meta-data 1.2, and nearly nobody uses it, 8 years after it was written. > When the packaging module is finally added (hopefully 3.4, even if > that means we have to temporarily cull the entire compiler > subpackage), it will handle the most recent accepted version of the > metadata format (as well as any previous versions). If more holes > reveal themselves in the next 18 months, then it's OK if v1.4 is > created when it becomes clear that it's necessary. The problem is that flooding people with specifications is a guarantee that they will not get implemented. So we can have one metadata specification every ten years; if we have more, none of them will be implemented (except in the tool of the author of the PEP). 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