On Jul 15, 2019, at 11:47, Abdur-Rahmaan Janhangeer <arj.pyt...@gmail.com> wrote: > > Greetings, > > Just like builtins module, would it be a good idea to have a stdlib module so > that we can know all modules in the std lib (just like builtins let us know > builtins)?
Is it just the names that are in stdlib, or some kind of lazy imports for the modules themselves, so you can do “from stdlib import pprint”? The latter is a bit more complicated, but it seems like it would make the feature a lot more useful—it’s a way to guarantee that you get the standard pprint even if it’s been shadowed by a local file, a way to make sure you get an early error if your distributor decided to leave pprint out of the distribution, and so on. And that would be similar to the builtins module (builtins.print is the builtin print, even if you’ve shadowed it with a module global). What exactly goes in stdlib? Would MicroPython include framebuf in stdlib, PyPI include cffi, etc.? Does it include things like test that are inside the lib/pythonX.Y directory but not intended to be imported? Or “accelerators” like _datetime, or other “internal” modules like _compression? What about __future__? Would Apple’s Python distribution include their extra modules like PyObjC, 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? You might want to take a look at https://github.com/abarnert/stdlib. Someone last year suggested something different but similar—a stdlib module that (lazily) includes the _ contents_ of every stdlib module, rather than the modules themselves—so I slapped together an implementation to play with the idea. Your suggestion should be a lot simpler—and potentially a lot more useful. So you really should consider implementing it and sharing live examples that people can play with themselves instead of having to explain everything. You can even put it on PyPI and see if it gets any traction. If people find it useful there—or, even better, if they find it useful but complain that it can’t do certain things (like tracking differences caused by distributors) without being part of Python itself—you’d have a great case. _______________________________________________ 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/JKMR3VZ62J2DSSGTSRMLZXIXRKLWDNFA/ Code of Conduct: http://python.org/psf/codeofconduct/
