<p dir="ltr"><br>
On 27 May 2015 18:18, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
> On Mon, 25 May 2015 17:30:02 -0700<br>
> Larry Hastings <<a href="mailto:larry@hastings.org">larry@hastings.org</a>> wrote:<br>
> ><br>
> > So, in all three cases it's work that's been under development for a<br>
> > while.  These people did this work out of the kindness of their hearts,<br>
> > to make Python better.  As a community we want to encourage that and<br>
> > make sure these developers know we appreciate their efforts.  These<br>
> > people would be happier if the work shipped in 3.5 as opposed to 3.6 so<br>
> > it got into user's hands sooner.<br>
><br>
> I second that sentiment. But it strikes me that we're doing this<br>
> because our release frequency is completely inadapted. If we had<br>
> feature releases, say, every 6 or 9 months, the problem wouldn't really<br>
> exist in the first place. Exceptions granted by the RM only tackle a<br>
> very small portion of the problem, because the long delay before an<br>
> accepted patch being in an official release *still* frustrates everyone,<br>
> and the unpredictability of exceptions only makes things *more*<br>
> frustrating for most players.<br></p>
<p dir="ltr">I'd actually like to pursue a more nuanced view of what's permitted in maintenance releases, based on a combination of the language moratorium PEP, and an approach inspired by PEP 466, requiring that every feature added in a maintenance release be detectable through an attribute check on a module (with corresponding support in dependency checking tools).</p>
<p dir="ltr">The problem with simply speeding up the release cycle without constraining the interim releases in some way is that it creates significant pain for alternate implementations and for downstream redistributors (many of whom are still dealing with the fallout of the Python 3 transition).</p>
<p dir="ltr">Cheers,<br>
Nick.</p>