<p dir="ltr"><br>
On 29 May 2015 01:04, "Steve Dower" <<a href="mailto:Steve.Dower@microsoft.com">Steve.Dower@microsoft.com</a>> wrote:<br>
><br>
> Paul Moore wrote:<br>
> > On 28 May 2015 at 15:28, Steve Dower <<a href="mailto:Steve.Dower@microsoft.com">Steve.Dower@microsoft.com</a>> wrote:<br>
> >> I don't have the issue number handy, but it should be near the top of<br>
> >> the recently modified list.<br>
> ><br>
> > I recall seeing that issue. I'm fine with that - getting the two in sync is<br>
> > obviously worth doing (and clearly in hand). I'm personally not sure whether<br>
> > automating the exposure of symbols is the correct approach, as I'm not sure<br>
> > people typically even consider the stable API when adding functions. Is the<br>
> > default (what you get if somebody just blindly adds a symbol with no thought for<br>
> > the stable API) to expose it or not? If the default is that it's not exposed,<br>
> > then automation seems reasonable, otherwise I'm not so sure.<br>
><br>
> Now I'm at my desk, the issue is<a href="http://bugs.python.org/issue23903"> http://bugs.python.org/issue23903</a><br>
><br>
> I believe new symbols are considered stable by default, so perhaps we actually want a test that will generate a C file that imports everything "stable" and will break the buildbots if someone adds something new without explicitly adding it to the list of stable functions?</p>
<p dir="ltr">The stable CPython ABI is actually tracked on <a href="http://upstream-tracker.org/versions/python_stable_api.html">http://upstream-tracker.org/versions/python_stable_api.html</a></p>
<p dir="ltr">Ideally we'd be running those checks automatically as part of our own QA with <a href="http://ispras.linuxbase.org/index.php/ABI_compliance_checker">http://ispras.linuxbase.org/index.php/ABI_compliance_checker</a>, similar to Antoine's regular refleak checks.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>