<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 15 Jun 2018, at 13:00, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" class="">ncoghlan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On 14 June 2018 at 06:30, Ronald Oussoren <span dir="ltr" class=""><<a href="mailto:ronaldoussoren@mac.com" target="_blank" class="">ronaldoussoren@mac.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On 13 Jun 2018, at 15:42, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank" class="">ncoghlan@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><br class=""><div class="">Yeah, pretty much - once we can get to the point where it's routine for folks to be building "abiX" or "abiXY" wheels (with the latter not actually being a defined compatibility tag yet, but having the meaning of "targets the stable ABI as first defined in CPython X.Y"), rather than feature release specific "cpXYm" ones, then a *lot* of the extension module maintenance pain otherwise arising from more frequent CPython releases should be avoided.</div><div class=""><br class=""></div><div class="">There'd still be a lot of other details to work out to turn the proposed release cadence change into a practical reality, but this is the key piece that I think is a primarily technical hurdle: simplifying the current "wheel-per-python-version-per-<wbr class="">target-platform" community project build matrices to instead be "wheel-per-target-platform”.<br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">This requires getting people to mostly stop using the non-stable ABI, and that could be a lot of work for projects that have existing C extensions that don’t use the stable ABI or cython/cffi/… </div><div class=""><br class=""></div><div class="">That said, the CPython API tends to be fairly stable over releases and even without using the stable ABI supporting faster CPython feature releases shouldn’t be too onerous, especially for projects with some kind of automation for creating release artefacts (such as a CI system).</div></div></div></blockquote><div class=""><br class=""></div>Right, there would still be a non-zero impact on projects that ship binary artifacts.</div><div class="gmail_quote"><br class=""></div><div class="gmail_quote">Having a viable stable ABI as a target just allows third party projects to make the trade-off between the upfront cost of migrating to the stable ABI (but then only needing to rebuild binaries when their own code changes), and the ongoing cost of maintaining an extra few sets of binary wheel archives. I think asking folks to make that trade-off on a case by case basis is reasonable, whereas back in the previous discussion I considered *only* offering the second option to be unreasonable.<br class=""></div></div></div></div></blockquote><div><br class=""></div>I agree. I haven’t seriously looked at the stable ABI yet, so I don’t know if there are reasons for now migrating to it beyond Py2 support and the effort required. For my own projects (both public and not) I have some that could possibly migratie to the stable ABI, and some that cannot because they access information that isn’t public in the stable ABI. </div><div><br class=""></div><div>I generally still use the non-stable C API when I write extensions, basically because I already know how to do so. </div><div><br class=""></div><div>Ronald</div><div><br class=""></div></body></html>