> On Jul 15, 2019, at 19:29, Christopher Barker <python...@gmail.com> wrote: > > I think this may be a worthwhile idea — after all, “namespaces are one > honking great idea” > > This would be an opportunity to clearly define the “standard library” as > something other than “all the stuff that ships with cPython”
I think a better current definition might be more like “all the stuff that has chapters in docs.python.org/library”. That documentation claims to define “The Python Standard Library” in the same way the reference defines “The Python Language”. (It also says to keep it under your pillow, which was not good for the screen of my tablet, but I’m not going to sue anyone over that.) But the fact that we don’t even agree on the current implicit definition is just more ammunition for your argument that we need an explicit definition. And having it enshrined in code (and tests!) seems even nicer. > No, they wouldn’t. The Stalin would be, well, a standard. Surely a Lenin level of forced standardization is sufficient; we don’t need to go full Stalin :) > If something is only going to exist on some platforms or implementations, > they should not be in that namespace. I’m not sure about that. Plenty of Unix developers think of modules like pty and termios as “part of the stdlib”. (I’m not sure if that’s the same for Windows devs with winreg and msvcrt, but it wouldn’t surprise me.) And they’re documented and built and delivered the same way as cross-platform libs. Why shouldn’t they be able to import them from stdlib? And if that is the rule, there’s a lot of room for bikeshedding on the edges. Does the stdlib then include curses because in theory it builds on any platform if the lib is found, even though in practice nobody builds it on Windows? Exclude multiprocessing and mmap because they’re not on all platforms, only Windows and Unix (including Mac and Linux, and even most third-party iOS and Android builds), which is all 99.9% of the Python world cares about? Exclude dis because it’s CPython-specific even though PyPy includes it as well? One more issue: packages. With a simple lazy importer design, there’s no way to make stdlib include the portable xml.etree but not the optional xml.parsers.expat; it either includes the xml package or it doesn’t. Is that what we want, or do we actually need lazily build proxy package objects for things like xml that lazy-import some things but reject others? And, if so, is it a problem that xml and stdlib.xml can both be imported at the same time and will have different contents? > A “pypy” or “upy” namespace would be the place to put those things. Then it’s > obvious to everyone where code that uses those will and won’t run. Only if everyone stops writing import spam and starts writing from stdlib/cpython/pypy import spam. Just because people _can_ now (with this change) do that doesn’t mean we want to encourage them to, much less expect them to. It wouldn’t just make code gratuitously incompatible with older Python, it would mark a very visible difference between most 3.9+ code and “legacy” code, given that most modules and scripts start off with stdlib imports right at the top. > Granted, something like MicroPython May never support the entire Stdlib, but > the goal should be to define what a “complete” stub is. Oh, that raises another point: there are a bunch of libraries that MicroPython does include; but only partially implements. If you from stdlib import cmath, should that fail, or should it do exactly the same thing as import cmath (that is, import fine, and work fine as long as you stick to the subset it supports, but NameError if you try to call, e.g., cmath.acosh)? For that matter, I believe every platform has a gc module, and they all share at least the three core functions, but beyond that everything is different. Should gc only be in stdlib on platforms where it includes all the documented functions? > > What about __future__? > > Nope: that isn’t really an import. Yes it is. It’s a magic name used by future statements, but it’s _also_ a perfectly normal module defined in __future__.py, included in the stdlib directory with every major implementation, and documented alongside things like sys and traceback. _______________________________________________ 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/HRE2NWRCOIPIU7QUUVDVD44PD5UCTIAN/ Code of Conduct: http://python.org/psf/codeofconduct/
