On Tue, Jul 16, 2019 at 4:44 AM Steven D'Aprano <st...@pearwood.info> wrote:
> > This would be an opportunity to clearly define the “standard library” as > > something other than “all the stuff that ships with cPython” > > CPython is the reference implementation. It is expected that anything > shipped by CPython ought to be shipped by all other implementations, > unless there's a very good reason not to. > I agree there, *almost*: I would define that is "anything in the CPython standard library should be shipped by all other implimentiatons" we cant inforce that of course, but if not, then you are shipping an incomplete implimentions (which I expect everyone using, e.g. micro Python knows). "A complete implementation" is more aspirational than a requirement. > but the goal should be to define what a “complete” stdlib is. > Please, let's avoid scope-creep. The proposal here is simple and > limited: make the std library modules available through a special > "stdlib" namespace. You call it scope-creep, I call it an opportunity. This would be an opportunity to provide a new definition for what "the standard library" means. And I think that would be very useful -- far more useful than simply providing a new namespace for all the cruft that is already in there. As someone said -- there is room for a lot of bike shedding around the edges -- so be it. If someone takes up the mantle and makes a test implementation and starts a PEP. then we will have a framework for that bike shedding. 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. Sure -- I'm not suggesting any enforcement mechanism -- just like now, HolyGrailPython can implement "import sys" to simply print "Ni". I don't suspect their users would like that, but that's up to them. All I'm saying is that the stdlib module could be defined as the platform-agnostic standard stuff -- so third party implimenters can make a decision about how compatible they should be. > We have a simple definition of "standard library", namely anything documented here: https://docs.python.org/3/library/index.html Which used to include SGI specific stuff, and still includes, e.g. macpath. I'm just suggesting that "ships with cPython" and "is the stdlib" should mean different things -- because that would be useful. Maybe I need to call it the "common library", rather than the standard library (from comlib import pathlib) -- would that seem useful to folks? > Only if everyone stops writing import spam and starts writing from stdlib/cpython/pypy import spam I was thinking that it would be: from comlib import pathlib from pypy import something_pypy_ specific (or pypylib maybe?) Anyone not using pypy would never use the pypy module And anyone that runs that code on another Pyton could get a far more meaningful error Granted, this would require people to start im porting from the comlib (Or stdlib, or...) module, but it would go a long way to have a pypy module, even if folks still used the regular imports for non pypy stuff. I thought the idea was the people would be encouraged to use the new namespace? Or was it just to have it there to inspect? If the latter, than my idea of restricting it might make even more sense :-) Anyway -- I"m not going to run with this, so whoever does gets to drive the discussion. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/TTFHN3NZ34LEPMSD4WBNQ7XQTOI75LBW/ Code of Conduct: http://python.org/psf/codeofconduct/
