> On Jan 20, 2017, at 9:26 AM, Yury Selivanov <yselivanov...@gmail.com> wrote: > > I think that we need to become less conservative about > development of CPython internals. At this point it's impossible > to make CPython any faster without invasive refactorings, and > I think it's OK to trust our core developers to make them.
I agree with the sentiment but I'm worried about the implications. Your suggested approach only makes sense if we have a good safety net in place to catch regressions early. Unfortunately, apart from regrtest, buildbots, and dumb luck, we don't. Betas have very limited adoption, too limited to be useful in my experience. I tried and failed to introduce 3.6 during beta phase at work because there was too much risk it would be picked up by unsuspecting users. Other users seem to be in the same camp. Consequently, most x.y.0 releases are relatively lower quality. I wonder if there's any way for us to incentivize beta usage in some key areas. For example, if every Python 3 project on Travis CI also ran on "3.7-dev" or "nightly", that would already give us better real world coverage. Actually *running* dev builds in production seems too risky for me for the reasons that Raymond and Victor state in this thread: too much lightly reviewed changes. Summing up, I don't think we can really start "moving fast and breaking things" until we have wider adoption of dev builds in the wild. To put money where my mouth is, I am currently working on introducing the dev version of 3.7 to the build system at work. But this is not going to be enough on its own. - Ł _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
