Barry writes (in part):

> 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*.

to which Stephen responds (in part):

> [Emacs really didn't change much in 20 years.] .... [I]n
> 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 seems to me that what we have is the possibility that, say, package
P migrates to PyPI in concert with the release of Python version X
where maintenance can be picked up by the broader Python community.
Whether or not it would proceed to track ongoing changes to the
language isn't clear, and it's not obvious to me that less effort
would be required other than perhaps by core devs (though some of them
would likely pitch in to maintain packages with which they are
currently involved). If you go with the "discard the batteries"
approach, I think it would at least be worthwhile distributing a
requirements.txt file ("sumo.txt" or "batteries.txt"?) which would
tell someone installing Python how to reclaim the batteries of their
Python youth, and for other Python implementations to track a set of
packages which would make them plausibly compatible with CPython. CI
could still rely on that to provide as much test coverage as current
today (I think). If nothing else, it might alert the core devs to the
potential for breakage of presumably widely used packages by changes
to CPython.

What happens to P when Python version Y grows a new syntactic feature?
Do P's maintainers fork to both continue feature growth as well as
syntactic modernization? If something like batteries.txt is created to
tie a slimmed-down CPython distribution to the batteries it once
contained, would the core group exert any control over unit testing,
documentation, package variations and such?

Just thinking out loud...

Skip
_______________________________________________
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/76ZTGO2PD6Q5NZOO5JWJRTTR2E2JY2H6/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to