Petr Viktorin <encu...@gmail.com> added the comment: > I wasn't aware that starting out with a PyPI module is the only accepted > process for getting functionality into stdlib.
It's the main way things should get in. (Other ways exist, for example, dataclasses were added as simplification/merging of several existing libraries.) > That certainly is a lot of work for what would be a trivial handful of lines > to parse key/value pairs and handle error paths, etc (and corresponding tests > of course). Releasing on PyPI is trivial once you have the tests and documentation. I'll be glad to help with that. > IMHO, forcing the PyPI route seems like a recipe for scope creep to me in > this case. Not necessarily. You just need to carefully define the scope of the PyPI module – same as you would for the stdlib module. There's not much difference between stdlib and PyPI here: after all, I'd argue the main reason platform.linux_distribution() was removed is that its scope was too wide to be maintainable. > The cost of adding Yet Another Dependency has to be paid in either case. Indeed. But it will be hard to get in otherwise. BTW, another way a PyPI release help is that the functionality would be useful for previous versions of Python. At this point new features are targetting Python 3.8. So, even if this does get into stdlib, a backport on PyPI would still be useful. Consider prior art like: https://pypi.org/project/dataclasses/ https://pypi.org/project/asyncio/ ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28167> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
