On Mon, Jul 15, 2019 at 01:36:06PM -0700, Andrew Barnert via Python-ideas wrote:
> What exactly goes in stdlib? The standard library modules documented at python.org. Note that being part of the std lib doesn't necessarily mean that it will be available, even on CPython. The contents of stdlib will be version specific, of course, and there are platform-specific modules too. Linux distros like Debian might shift them to a different OS package (deb or rpm) so they may be missing if the user didn't install all the packages. > Would MicroPython include framebuf in > stdlib, PyPI include cffi, etc.? They're not (I presume...) maintained by the CPython core devs and documented as standard library modules, so no. > Does it include things like test that > are inside the lib/pythonX.Y directory but not intended to be > imported? Are they documented as public modules at python.org? Then yes, otherwise no. > Or “accelerators” like _datetime, or other “internal” > modules like _compression? Since they're private modules, it should make no difference to anyone except the implementer of the public module. If the maintainer of datetime wants _datetime in the stdlib namespace, that is not part of the datetime public interface. > What about __future__? Despite the dunder name, it's a standard (and ordinary) public module: https://docs.python.org/3/library/__future__.html so yes, it is a standard library module that ought to appear in the stdlib namespace. > Would Apple’s Python > distribution include their extra modules like PyObjC, Is it documented at python.org as a standard library module? If so, then yes, if not, then no. > and would > Debian’s exclude the ones they’ve taken out of the python package and > put in separate debs? Is there a distributor and/or site mechanism for > customizing this? There's no need to customize it. If Debian removes (let's say) the math module, because reasons, then from stdlib import math will fail unless the user has installed the python-math deb. Let's KISS and not complicate it to the point it can't happen. We have a simple definition of "standard library", namely anything documented here: https://docs.python.org/3/library/index.html including the optional components. If there's some special case (let's say, the HovercraftFullOfEels module, which we want to document but for some reason we don't want to be accessible in the stdlib namespace), then its fine for it to be left out (and documented as such). We ought to discourage implementations adding non-std libs to the stdlib namespace, but compliance is a Quality of Implementation issue, not a deal-breaker. If HolyGrailPython wants to package stdlib.black_knight we should neither encourage nor prevent them from doing so, but can "tut tut" loudly whenever anyone complains that from stdlib import black_knight fails in CPython. -- Steven _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6GGEDIEGZ3FQ2ULSRPABIARLWYPG47R5/ Code of Conduct: http://python.org/psf/codeofconduct/
