On Wed, Dec 4, 2019 at 6:37 PM Victor Stinner <vstin...@python.org> wrote:
> Le mer. 4 déc. 2019 à 14:49, Thomas Wouters <tho...@python.org> a écrit : > >> (...) > >> It's very different if an incompatible change break 1% or 90% of > >> Python projects. > > > > Unfortunately there is a distinctive bias if you select popular > projects, or even packages from PyPI. There is a very large body of work > that never appears there, but is nonetheless used, useful and maintained > lacklusterly enough to pose a big problem for changes like these. > Tutorials, examples in documentation, random github repos, plugins for > programs that embed Python, etc. The latter also represents an example of > cases where you can't just decide to use an older version of Python to use > something that wasn't updated yet. > > My point is that currently, we have no data to take decisions. We can > only make assumptions. Having more data than nothing should help to > take smarter decisions ;-) > It should, but it doesn't always :) If you forget how your data is flawed, the 'smarter' decision can easily be wrong, instead. I do think it's a good idea to reject ideas that would break a certain number of PyPI packages, say, but just because it won't break them doesn't mean it won't break a significant number of others. > > I know that there is closed source and unpublished projects. But if > 20% (for example) of the most popular projects on PyPI are broken by > an incompatible change, it's not hard to extrapolate that *at least* > 20% of unpublished will be broken at least. Usually, closed source and > unpublished projects are getting less attention and so are less up to > date than PyPI projects. > > Even if you restrict the scope to PyPI: most PyPI top 100 modules are > the most common dependencies in projects. It's easy to extrapolate > that if 20% of these PyPI top 100 modules are broken, all applications > using at least one of these broken projects will be broken as well. > > Another point of the PEP 608 is that there are not often resources to > fix the most popular dependencies on PyPI, it's likely better to > *revert* the incompatible change causing the issue. Again, to be able > to revert a change, we need the information that we broke something. > If a change goes through the final release, usually we prefer to > acknoledge that the "ship has sailed" and deal with it, rather than > reverting the annoying change. > > Victor > -- > Night gathers, and now my watch begins. It shall not end until my death. > -- Thomas Wouters <tho...@python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!
_______________________________________________ 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/EZRSZQVS4AB6AJQYT4XV4B2H4OCOE4LB/ Code of Conduct: http://python.org/psf/codeofconduct/
