On Tue, Jul 16, 2019 at 3:22 PM Steven D'Aprano <st...@pearwood.info> wrote:
> > > 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? > no -- "should" and "ought" are synonyms in this context - the difference is "shipped by CPython" vs "in the CPython standard library". cPYton ships stuff that is cPython specific, doesn't it. 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. > Frankly it is unlcear to me what "the proposal" actually is anyway, so it's an opportunity to to something more expansive that provide a module that does nothing but provide the exact same information that is already in the docs (and implicit in the fact that third party libraries are usually installed in site-packages). The OP did refer to being able to point people to __builtins__ to see what's built in. It that's the only goal here, then we could make a simple "list_stdlib_modules" function. > 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? > I'm made that point already -- you may not agree, but the idea is that there are things that "ship with cPython" and there are things that are really designed to be generically useful and counted on everywhere. I think that's a useful distinction. There is even a discussion right now on what to remove (or deprecate) from the stdlib -- perhaps there is a middle option -- keep it,but make it no longer part of the "common library". > 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. > it would be a subset -- but yes, that's the idea :-) > 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. > see above -- not necessarily -- in fact, leaving deprecated modules out of the stdlib namespace would be one good use case for my idea -- it would be far more clear that you were using something that is no longer "standard". > (What you call "cruft", someone else may call "critically important > library I couldn't do without".) > Of course -- which is again why it could be useful to still give that user access, while also signaling clearly that they are using non-standard features. > 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. > I think it's worth drawing a line between behaviour and features. platform-specific behaviour is too bad, but probably unavoidable. But I've always (which goes back to Python 1.5) thought that putting platform-specific behaviour in standard modules was a wart. My prime example is the os module -- it is a wrapper around platform specific modules, and most of it provided platform-nuetral features, but a there are a few oddballs in there. Why do I care? because folks can write code on a posix system, and have no idea that that code won't work on, e.g. Windows. It wouldn't seem such a burden to do: import os and then, when you posix only features -- import posix Making it very clear that that particular part of the code will only run under posix. > -- 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? > of course they can -- nothing would change in that regard. > > 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. > exactly my point -- should all that be in the same namespace? It has been because there was only one namespace anyway. > Do you think there are many (e.g.) POSIX developers who are confused by > the lack of winreg module? of course not -- but that actually proves my point -- by calling in the "winreg" it is clearly a Windows thing. ANyhone using it will not expect that code to run on non-windows system. But if it were called "systemconfig", that would be a different story. How is the "common library" different from the standard library? > Because "We already have a definition of the standard library", and that definition is "everything that ships and is documented with cPython" My suggestion is that we make something *new* which has a different defintion, and then people wont be saying that I'm proposing breaking things -- it's something different, maybe it should have different name. > pathlib is another one of the major standard library modules that fails > to be platform-agnostic. > Though its intention is to provide a consistent interface for path manipulation -- and certainly most of it is consistent -- I'll take your work for it that not all of it is, but certainly most is. One reason folks should use it rather than doing things like: my_path = dir_name + r"\" + filename The fact is that Python is almost entirely platform agnostic, which is a really great feature -- I'm suggesting it would be a tad better if the non-standard parts were more clearly labelled, that's all. > 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' > There is a substantial difference -- a user of the first version has to think "why the heck don't I have the cffi module? I had it on that other machine, and it's not listed in requirements, nor on PyPi?? A user getting the second version can immediately see that the missing module is related to PyPy. even worse, under this proposal, they would get: py>from stdlib import cffi # PyPy specific Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named 'cffi' And think "what the heck, it's in the darn standard library ?!?! I must have a broken install".... All this is not all that big a deal, but if the definition of the "stdlib" module doesn't change at all, then I can't see the point of the proposal. But I don't have time to actually do any of this work for my idea, so we'll see what the OP comes up with. -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/S2ZJVR3DWCESJFI27OYYDF5X4UHBJ5LE/ Code of Conduct: http://python.org/psf/codeofconduct/
