On Tue, Jul 16, 2019 at 09:50:19AM -0700, Christopher Barker wrote:
On Tue, Jul 16, 2019 at 4:44 AM Steven D'Aprano
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"
Is there a difference in meaning between "ought" and "should" here? Because I can't tell what the "almost" is here. What is the difference between what I said and what you said? [...]
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.
Yes: an opportunity to bike-shed, an opportunity to derail the proposal, an opportunity to increase the complexity of the proposal by an order of magnitude without a corresponding increase in usefulness.
This would be an opportunity to provide a new definition for what "the standard library" means.
Why do we need a new definition for std lib that differs from the definition used for 30 years, one which is universally understood by Python developers and referenced in books and blog posts and Stackoverflow answers everywhere? We have a reference implementation (CPython) that defines the std lib. How is it helpful to distinguish between these? 1. The standard library modules which are documented in the reference manual, and maintained by the core developers; 2. and a *different* set of modules (maybe a subset, maybe a superset) which may or may not be "standard" in the sense above but will appear in the stdlib namespace. (These are not rhetorical questions. If you want to make a case for the usefulness of this, go right ahead.)
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.
Whether it is cruft or not is an unrelated issue. Modules can still be deprecated, they can still be removed. But so long as they remain in the std lib, then they would remain accessible in the stdlib namespace. (What you call "cruft", someone else may call "critically important library I couldn't do without".) [...]
All I'm saying is that the stdlib module could be defined as the platform-agnostic standard stuff
There's a lot more platform-dependent features and behaviour in the stdlib than most people realise, and if we start excluding anything which is not platform-agnostic, we'd exclude major modules as: sys, os, stat, time, subprocess, shutil, math, datetime, random all of which include platform-specific behaviour or features.
-- so third party implimenters can make a decision about how compatible they should be.
Are you suggesting that implementers can't currently make that decision?
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.
So? It also includes Windows specific stuff, and POSIX specific stuff.
I'm just suggesting that "ships with cPython" and "is the stdlib" should mean different things -- because that would be useful.
Just repeating "it would be useful" doesn't make it so. How would it be useful? Do you think there are many (e.g.) POSIX developers who are confused by the lack of winreg module? If not, what problem are you trying to solve by redefining the standard library?
Maybe I need to call it the "common library", rather than the standard library (from comlib import pathlib) -- would that seem useful to folks?
How is the "common library" different from the standard library? pathlib is another one of the major standard library modules that fails to be platform-agnostic. [...]
And anyone that runs that code on another Pyton could get a far more meaningful error
I don't see that there is much difference between: py> import cffi # PyPy specific Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named 'cffi' py> from pypy import cffi Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named 'pypy' -- Steven