Barry Warsaw writes: > While I don’t underestimate the work and complexity, we can do > both. I.e. separate the stdlib development cycle from the > interpreter (for all but a handful of required packages perhaps). > We could still distribute “sumo” releases which include all the > batteries, but develop and maintain them outside the cpython repo, > and even release them separately on PyPI. It’s *possible* but I > don’t know if it’s *practical*.
After a couple decades maintaining XEmacs, I'd have to say that one of the things that made our sumos (you heard that word here first, folks!) practical was that about 80% of the code was developed in GNU Emacs. That is, developed in concert with core Emacs. This meant that dependencies (think "hybrid of hydra, kitsune-yokai, and ouroboros" :-) evolve together, as they do in Python. This is probably more important in Emacs because of the big-ball-of-string nature of big Lisp systems (at least with a relatively undisciplined dev process), but I'd still say there would be *substantial* coordination costs to be paid if you split the repos. Also, the only feature in Emacs Lisp that really changed the way people code since 1990 (and likely earlier) is lexical scope. Everything else is merely a new callable for practical purposes, and almost all of it can be implemented in Lisp either as a function or a macro (although usually at great expense in performance). But in Python, every new release makes the Mailman crew want to stop supporting all previous releases of Python because there's some feature that can't be emulated that we really love: genexps or async or walrus operator or .... It was certainly quite costly in XEmacs trying to most packages usable in 21.4, mostly in frustration about not being able to use 21.5 features. ;-) But Python has like 4 or 5 generations of stdlib in some form of development or maintenance at any given time. It's really not attractive to think either about creating a separate Sumo Dev Core to maintain several generations of stdlib corresponding to in-maintenance versions of Python, or about a lowest-common-denominator stdlib. Until XEmacs split off the stdlib into packages, Emacs didn't have anything like a package repository, certainly nothing like PyPI. I don't have experience with the Emacs package repos ELPA and MELPA for, uh, hysterical raisins, so season the next comment to taste. My feeling is that both splitting out the stdlib and increasing the rate at which new packages are added are excessively expensive non- solutions to the problem that Paul has described, that finding the right package on PyPI is pretty hard, especially for people new to a technology. The extra effort that would be needed to achieve either, as well as the increased on-going maintenance burden on the core team, would not really resolve the problem, given that there are now whole large ecosystems like Django and SciPy outside of Python core development. Although it's a different kind of effort from package incorporation and maintenance, to the extent that effort is fungible, I think it would be better devoted to creating an annotated catalog of PyPI. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZKODGJ3I6XQNX7ISE4EVCI5RVRCTTOA4/ Code of Conduct: http://python.org/psf/codeofconduct/
