[Python-Dev] Re: Proposal: declare "unstable APIs"

On Fri, 4 Jun 2021, 4:17 am Gregory P. Smith, wrote: > Overall agreement. Your list of ast and code objects and bytecode > instructions are things that I'd _hope_ people already consider unstable so > declaring them as such just makes sense if we're not doing that already. > Another example of

[Python-Dev] Re: Proposal: declare "unstable APIs"

06.06.21 06:48, Guido van Rossum пише: > On Fri, Jun 4, 2021 at 6:15 AM Victor Stinner > wrote: > If possible, I would prefer to make PyThreadState, PyCodeObject and > other structures opaque, and only go through getter and setter > functions ;-)

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Sat, Jun 5, 2021 at 2:12 AM Serhiy Storchaka wrote: > 04.06.21 12:08, Petr Viktorin пише: > > It is used, and I started the work :) > > See e.g. > > https://docs.python.org/3.10/c-api/sequence.html#c.PySequence_Concat > > Great news! Several core developers (including me) tried to solve this

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Fri, Jun 4, 2021 at 6:15 AM Victor Stinner wrote: > On Fri, Jun 4, 2021 at 12:29 AM Guido van Rossum wrote: > >> In the C API, there is the internal C API which fits with your > >> description. To access it, you have to declare the > >> Py_BUILD_CORE_MODULE macro. It's not usable directly on

[Python-Dev] Re: Proposal: declare "unstable APIs"

04.06.21 12:08, Petr Viktorin пише: > It is used, and I started the work :) > See e.g. > https://docs.python.org/3.10/c-api/sequence.html#c.PySequence_Concat Great news! Several core developers (including me) tried to solve this problem, but a large amount of work stopped us at an early stage.

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Fri, Jun 4, 2021 at 12:29 AM Guido van Rossum wrote: >> In the C API, there is the internal C API which fits with your >> description. To access it, you have to declare the >> Py_BUILD_CORE_MODULE macro. It's not usable directly on purpose. It's >> an user agreement: I know what I am doing,

[Python-Dev] Re: Proposal: declare "unstable APIs"

Am 03.06.21 um 20:11 schrieb Gregory P. Smith: The ideal way to declare an API as unstable is to constantly change it in a breaking manner.  With every release and potentially even within some patch releases when the point really needs to be made.  Even when you didn't have a reason to change

[Python-Dev] Re: Proposal: declare "unstable APIs"

On 04. 06. 21 10:25, Serhiy Storchaka wrote: 03.06.21 20:10, Guido van Rossum пише: This is not a complete thought yet, but it occurred to me that while we have deprecated APIs (which will eventually go away), and provisional APIs (which must mature a little before they're declared stable),

[Python-Dev] Re: Proposal: declare "unstable APIs"

03.06.21 20:10, Guido van Rossum пише: > This is not a complete thought yet, but it occurred to me that while we > have deprecated APIs (which will eventually go away), and provisional > APIs (which must mature a little before they're declared stable), and > stable APIs (which everyone can rely

[Python-Dev] Re: Proposal: declare "unstable APIs"

Maybe ‘version-dependent’ api? It indicates why the api is unstable (as opposed to something like test.support where the docs say ‘this is for us, we’re not bothered about keeping it stable’). In some contexts ‘unstable’ means buggy/unreliable. > On 4 Jun 2021, at 00:20, Glenn Linderman

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Fri, Jun 4, 2021 at 8:31 AM Guido van Rossum wrote: > > On Thu, Jun 3, 2021 at 2:01 PM Chris Angelico wrote: >> >> On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote: >> > >> > I think it makes sense, and I do see a difference between Provisional and >> > Unstable. Is this anything more

[Python-Dev] Re: Proposal: declare "unstable APIs"

On 6/3/2021 3:34 PM, Guido van Rossum wrote: On Thu, Jun 3, 2021 at 3:17 PM Tim Delaney mailto:timothy.c.dela...@gmail.com>> wrote: Perhaps "living API" analogous to "living document". Much more positive connotations ... Perhaps, but that's pretty much coining a new term, which we

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Thu, Jun 3, 2021 at 2:01 PM Chris Angelico wrote: > On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote: > > > > I think it makes sense, and I do see a difference between Provisional > and Unstable. Is this anything more than a documentation label? > > > > Would it be a pipe dream to hope

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Thu, Jun 3, 2021 at 3:17 PM Tim Delaney wrote: > Perhaps "living API" analogous to "living document". Much more positive > connotations ... > Perhaps, but that's pretty much coining a new term, which we would then have to explain. And since the opposite would be "dead API", what is a dead

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Thu, Jun 3, 2021 at 1:33 PM Victor Stinner wrote: > Hi Guido, > > It seems like you are talking about the Python API. > Primarily, yes. In the C API, there is the internal C API which fits with your > description. To access it, you have to declare the > Py_BUILD_CORE_MODULE macro. It's not

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Fri, 4 Jun 2021 at 03:13, Guido van Rossum wrote: > This is not a complete thought yet, but it occurred to me that while we > have deprecated APIs (which will eventually go away), and provisional APIs > (which must mature a little before they're declared stable), and stable > APIs (which

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Fri, Jun 4, 2021 at 6:44 AM Barry Warsaw wrote: > > I think it makes sense, and I do see a difference between Provisional and > Unstable. Is this anything more than a documentation label? > Would it be a pipe dream to hope that static checkers could be taught to recognize them? Not a huge

[Python-Dev] Re: Proposal: declare "unstable APIs"

I think it makes sense, and I do see a difference between Provisional and Unstable. Is this anything more than a documentation label? -Barry > On Jun 3, 2021, at 13:10, Guido van Rossum wrote: > > This is not a complete thought yet, but it occurred to me that while we have > deprecated APIs

[Python-Dev] Re: Proposal: declare "unstable APIs"

Hi Guido, It seems like you are talking about the Python API. In the C API, there is the internal C API which fits with your description. To access it, you have to declare the Py_BUILD_CORE_MODULE macro. It's not usable directly on purpose. It's an user agreement: I know what I am doing, and I

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Thu, Jun 3, 2021 at 11:11 Gregory P. Smith wrote: > One obvious now in hindsight question: Why are any of these APIs even > public? They all deserve underscore prefixed names to highlight their > private-ness and potential instability. > Because they are still useful when manipulating or

[Python-Dev] Re: Proposal: declare "unstable APIs"

Overall agreement. Your list of ast and code objects and bytecode instructions are things that I'd _hope_ people already consider unstable so declaring them as such just makes sense if we're not doing that already. The ideal way to declare an API as unstable is to constantly change it in a

[Python-Dev] Re: Proposal: declare "unstable APIs"

In practice, provisional APIs have been quite stable. The term "provisional" was introduced for PEPs that introduce new modules, where we wanted to allow some wiggle room for changes based on experience with using the new module during the first release cycle where it's made available. You can

[Python-Dev] Re: Proposal: declare "unstable APIs"

On Thu, Jun 03, 2021 at 10:10:53AM -0700, Guido van Rossum wrote: > This is not a complete thought yet, but it occurred to me that while we have > deprecated APIs (which will eventually go away), and provisional APIs (which > must mature a little before they're declared stable), and stable APIs