[python-committers] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

[Yury Selivanov]

On 2017-01-20 5:02 PM, Lukasz Langa wrote:
>> On Jan 20, 2017, at 9:26 AM, Yury Selivanov <yselivanov.ml at 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