On Wed, 14 Nov 2018 at 14:39, Paul Moore <p.f.mo...@gmail.com> wrote:
> If it is the case that there's no need for any 3rd party code to > change in order to continue working with 3.8+, then I apologise for > the interruption. This is where being able to edit posts, a la Discourse would be useful :-) It occurs to me that we may be talking at cross purposes. I noticed https://pythoncapi.readthedocs.io/backward_compatibility.html#forward-compatibility-with-python-3-8-and-newer which seems to be saying that 3rd party code *will* need to change for 3.8. You mention removed functions there, so I guess "stop using the removed functions and you'll work with 3.8+ and <=3.7" is the compatible approach - but it doesn't offer a way for projects that *need* the functionality that's been removed to move forward. That's the type of hard break that I was trying to ask about, and which I thought you said would not happen when you stated "I don't want to force anyone to move to a new experimental API", and "No, the current C API will remain available. No one is forced to do anything. That's not part of my plan". So to try to be clear, your proposal is that in 3.8: 1. The existing C API will remain 2. A new C API will be *added* that 3rd party projects can use should they wish to. And in 3.9 onwards, both C APIs will remain, maybe with gradual and incremental changes that move users of the existing C API closer and closer to the new one (via deprecations, replacement APIs etc as per our normal compatibility rules). Or is the intention that at *some* point there will be a compatibility break and the existing API will simply be removed in favour of the "new" API? Fundamentally, that's what I'm trying to get a clear picture of. The above is clear, but I don't see what incentive there is in that scenario for anyone to actually migrate to the new API... Paul _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
