1. 28

  2. 12

    Kernelization has its disadvantages.

    Right now, Python is a terrific introduction language. It’s simple yet regular syntax makes it easy to teach, and the full-featured standard library provides much of what a new programmer could want. Maybe not the best and newest takes on various domains, but more than enough for a beginner with modest means. All this comes in a single package from python.org.

    The article suggests that we “kernelize” Python by removing a default “user space” of standard libraries and move those libraries like pip to an installer model.

    Teaching dependency management with pip and all its friends (venv? Peotry? Pipenv?) sounds fraught to me - and unfriendly to beginners when the ecosystem and best practices seem to be in such flux.

    We might also see that change will fragment Python - like Linux - into a myriad of competing distributions. There are already Python “distros” like conda out there, but a kernelized Python almost necessitates that everyone pick a distro. One more extra burden of choice and burden of research for a newcomer.

    This is a good take for technical experts (this crowd) but a poor one for learners and approachability. How much easier would Linux be to learn if there was Only One Way to do it?

    1. 4

      Agree 100%. One of Pythons greatest strengths is its decent standard library, and built in package manager:


      I am fine with slimming down standard library, but dont remove it. We dont want to turn Python into C, where the standard library has almost nothing. All it does it force novice users to create their own their own terrible solution, or send them hunting into a forest of thousands of packages. One of the biggest pain points for me with any language is finding something I consider “basic” not in the standard library, and trying to figure out what package to use. Dont put that hassle on the community.

      Deciding where to draw the line is a hard problem yes, but the alternative of no standard library is worse.

      1. 4

        Maybe the answer is two tier: core and stdlib. Core could be a narrow subset of modules that make up the base of the language and stdlib could be bootstrapped off of core (i.e., stdlib is all python code written using core or other stdlib). It would make it much easier to port stdlib to other pythons.

        Of course it would take rewriting stdlib in some subset of modules that are deemed core. Would take a lot of work I imagine.

      2. 2

        The article suggests that we “kernelize” Python by removing a default “user space” of standard libraries and move those libraries like pip to an installer model.

        As I read it (and here I’m speaking with the benefit of knowing the author, and also knowing the author of the piece he refers to in the intro), the article is being deliberately hyperbolic in mentioning the Kondo approach. The actual suggestion is:

        We need a “kernel” version of Python that contains only the most absolutely minimal library, so that all implementations can agree on a core baseline that gives you a “python”, and applications, even those that want to run on web browsers or microcontrollers, can simply state their additional requirements in terms of requirements.txt.

        A baseline set of modules significantly smaller than the current Python standard library is a provocative idea, but not necessarily new or even particularly radical; as Glyph points out, Linux distributions have a history of breaking up Python’s standard library across multiple separate distro packages, and while it’s been an annoyance for people who maintain things that depend on the standard library being shipped whole, it also seemingly hasn’t killed Python’s growth and adoption. And standardizing the minimal subset that gets to be called a distribution of Python would go a long way toward reducing the headaches imposed by distros’ current fragmentation of the standard library.

        Teaching dependency management with pip and all its friends (venv? Peotry? Pipenv?) sounds fraught to me - and unfriendly to beginners when the ecosystem and best practices seem to be in such flux.

        This I think is a bit unfair as a criticism, because most of the variation in workflows is on the producer side of packaging, not the consumer side. Consumers of Python packages don’t need to know or care what toolchain someone used to produce those packages. The main split on the consumer side is between users of pip and users of conda, which is is really more of a split between sub-communities working in different problem domains (a rough and grossly oversimplified description might be: if you’re writing networked applications you’re probably a pip user; if you’re doing numeric/scientific computing you’re probably a conda user).

        1. 1

          Would a ‘satellite’ language, let’s call it PythonBare – be an ‘in-between’ option ? it will be part of standard python distro, but could also be distributed without the main ’big Python.

          Just trying to draw analogies between BetterC (a subset of D) and this discussion. I think for purposes of D, to have a language with D syntax, that can directly leverage pre-installed C-libraries is a big deal.

          Although, thinking about it, not sure, to be honest, if the above analogy/benefit extends to Python world – because ‘PythonBare’ still can only use python libraries.

          On another hand if PythonBare could some how automagically import and leverage without any wrappers available C-libraries, then may be there is an advantage (similar to BetterC or Zig ).

          1. 2

            From my relatively uninformed viewpoint, it sounds like both RPython or Cython might be a suitable starting point for your BarePython idea.

            RPython is a restricted set of Python that’s used to implement the PyPy JIT runtime. Not all methods are available, and things like interators are simplified.

            Cython is a compiles extension language that easily inter-operates with C and Python. It’s not clear to me if Cython can use Python stdlib imports.

          2. 0

            It’s simple yet regular syntax makes it easy to teach

            I feel like this is becoming less and less true. Annotations are not particularly simple, how everything works together in Async is quite complicated actually (thats actually true for many things in Python), lots and lots of new syntax with only little use being introduced.

            Python seems to try to become everything for everyone but is not tackling the elephant in the room which is the terrible package management. As you say, better have a large stdlib of obsolete code than to refer beginners to the horror that are virtual environments and its managers. Which is sad, because node manages to get by with a rather small standard library since installing things using npm is feasible.

            I always felt that this whole easy_install, setuptools, pip, virtualenvwrapper, venv, pipenv, etc etc. stuff was only necessary because CPython has no good way of handling envirornments on its own so everybody just tries to get by with juggling PYTHONPATH. Implementing a better way of locating modules in CPython could make this pain go away.

          3. 7

            I think this is a bad idea because it’s worse for beginners. It’s also self-serving to the Twisted community that has felt spurned for a long time. We’re optimizing for the future Python programmers who will far out number us, and “batteries included” is the way to do that.

            1. 3

              Why is it self serving to the Twisted community?

              1. 6

                Because they want asyncio removed from the standard library because it competes with Twisted. Some more context here: http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html

                1. 3

                  Because they want asyncio removed from the standard library because it competes with Twisted.

                  I think that’s a very uncharitable reading of the situation. The suggestion is that much of the standard library become third-party on PyPI, not that the modules be eliminated altogether. And the reasoning is pretty sound: it’s an absolute pain to know that something was just added to the Python standard library but you can’t use it because it’ll be at least half a decade until enough users have migrated to a version of Python that has it. If the modules were on PyPI, you’d just tweak the version in your own dependency declaration and be able to rely on it same-day.

                  1. 1

                    Your comment doesn’t make sense to me. Can you clarify? Is “half a decade” a reference to Python 3? There were backports to 2 (https://pypi.org/project/trollius/). Yield from wasn’t in Python until 3.3, and there was a separate package for that version (https://pypi.org/project/asyncio/). What makes asyncio feel good is async and await which didn’t arrive until 3.5, and that’s syntax that you can’t install as a module.

                    We’re trying to optimize for new programmers, and the last thing they should be learning about is package management. It’s hard enough to just learn the language and become productive.

                    1. 1

                      A given Python release series (like 3.7.x) tends to have a support lifetime of around five years from the Python core team. And your installed base as an application developer is going to include a lot of corporate users who standardize on a version and ride it until upstream support ends (or even longer). Since you can’t count on people doing timely upgrades of their Python interpreter + stdlib, you can’t count on them being able to use anything that depends on more recent Python features.

                      We’re trying to optimize for new programmers, and the last thing they should be learning about is package management.

                      Unless you’re giving them a custom distribution of Python that also includes Flask, Django, the full numpy/scipy stack, Jupyter, ML/AI libraries and game toolkits in a single install, they’re going to have to learn how to type pip install at some point in order to be productive beyond the intro to the language.

                      And being a consumer of Python packages is not particularly difficult these days, because it really is just pip install. The variation in toolchains and techniques is almost all on the producer side of packaging, and is mostly invisible to people who just want to install and use unless we scare them off by inaccurately telling them there are dozens of competing options.

                      1. 2

                        I think you’re conflating corporate users of Python with beginners. The point here is that we’re trying to delay the need to install any extra Python packages for as long as possible to maximize proficiency before users have to learn a second tool (pip in this case). If the standard library is empty then beginners have two problems to confront in order to learn the language. It’s a really simple concept.

                        1. 1

                          Nobody’s saying there should be no standard library. Several people are suggesting a much smaller standard library that contains only the really essential things, and move the rest to PyPI.

                          You can still teach beginners how to write functions and classes and do things with just the language itself and zero import statements. And like I said, at some point if they want to write anything non-trivial either you need to be providing a bundled installer that has extra stuff in it, or they need to learn to run pip install.

                          1. 1

                            os, io, pdb, unittest, functools.wraps, collections, socket, … – all of these should be in PyPI? My advice would be to switch to JavaScript and npm if that’s what you want. With Python: “There should be one– and preferably only one –obvious way to do it.”

                            1. 2

                              I keep telling you what people are actually proposing. You keep refusing to engage with that and instead setting up straw men you can knock down. So I’m not going to spend any more time on this.

              2. 1

                Are there links on how you are going about this?

                1. 4

                  This post from one of the core devs covers it pretty well I think:


                  1. 2

                    Thank you for the link. This did not cover anything about the standard library, but it was helpful to get the perspective on Python 3.

                    So expect Python 4 to not do anything more drastic than to remove maybe deprecated modules from the standard library.

                    When I got to this line it became clear to me that the Twisted community and Python core devs are talking past each other.

                    1. 2

                      There is now a draft PEP suggesting that Python deprecate and remove some of the “dead batteries” in the standard library. There’s no reason, in 2019, for every Python user on earth to devote bandwidth to download, and disk space to storing, copies of a module for working with the audio files from 1990s Sun workstations (to take one egregious example of something that’s in the standard library with no real right to be).

              3. 4

                Obviously the author has a much greater experience with Python than I do. But maybe Python doesn’t need to expand into the browser? maybe Python doesn’t need to expand into Apps. I like Python because I know it works as is. I don’t want to have more knobs on it.

                1. 5

                  Another rant from the Twisted community about python stdlib. OK.