On 2017-01-20 5:02 PM, Lukasz Langa wrote:
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.
- Ł
Lukasz, I understand what you are saying here. But on the other hand,
we should not stop improving CPython. Sometimes stuff will break
because of our "loose" safety net, but this is inevitable. It happens
virtually in any software project (including other languages and compilers).
My experience shows that even extensive code reviews don't spot all
bugs. E.g. I missed a bug in one asyncio patch that caused
"loop.sock_connect" to be broken in 3.5.2. Another one: due to a design
mistake in PEP 492, we had to change how __aiter__ behaves in 3.5.3 and
3.6. PEP 492 was thoroughly discussed, the patches were reviewed, and
we merged everything a few months before we released Python 3.5.0; that
wasn't enough apparently.
I'm not suggesting that we should "move fast", merge things without
reviews / tests / benchmarks. In Victor's case, he started working on
FASTCALL in 3.6, and we already shipped some of his improvements (I
reviewed a few FASTCALL patches myself). Now he (with help of Serhiy
and Inada-san) simply continues to work on the project, gradually
refactoring the code, improving Argument Clinic etc. We are still early
in 3.7 development cycle, and I don't think we should stop the project
just because we had a couple of minor regressions.
Thank you,
Yury
_______________________________________________
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/
