[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

STINNER Victor added the comment: Would it be the right place to document the new CodeType.replace() method which is designed to help to write "future-proof" code? (not rely on the exact constructor API) -- nosy: +vstinner ___ Python tracker

[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

Petr Viktorin added the comment: New changeset 13136e83a637a9f1cfbada7e93097005296659b4 by Petr Viktorin (Matthias Bussonnier) in branch 'master': bpo-36896: Clarify that some types constructors are unstable (GH-13271)

[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

Terry J. Reedy added the comment: Yes, I think " Not for the faint of heart." could be replaced or augmented by 'api may change' -- ___ Python tracker ___

[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

Matthias Bussonnier added the comment: > I don't believe we put version changed notes in docstrings, Oh no I was thinking a note in the docstring "constructor signature may change between Python versions". Whether to put changed/addition info in docstrings is another subject and a thing I

[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

Terry J. Reedy added the comment: Pablo, I am all for respectfully preserving implementation freedom where we can. From idlelib.__init__: [idlelib files other than idle*.*] "are private implementations. Their details are subject to change. See PEP 434 for more. Import them at your own

[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

Matthias Bussonnier added the comment: Victor recently implemented CodeType.replace(); which I believe will cover many of the usecase. Should I also send a PR that update the DocStrings of (some of) ? these objects? many people don't go and read the html docs... --

[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

Pablo Galindo Salgado added the comment: Being said that, I am very happy with the current changes on the PR :) Thank you @Terry and @Petr for helping with this! -- ___ Python tracker

[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

Pablo Galindo Salgado added the comment: Although I completely agree with the decision of figuring out an explicit consensus regarding these APIs, I will explain a bit my +1: My +1 is not about the usage of PyCode_New, is about the usage of `types.CodeType`. The constructor for the later

[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

Terry J. Reedy added the comment: In msg342227 Pablo Galindo Salgado said "I am +1 to such a sentence, but I think this is a decision that more core devs should agree on." > "These types are not supposed to be instantiated outside of CPython internals" At least Petr Vidtorin and I disagree

[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

Change by Matthias Bussonnier : -- keywords: +patch pull_requests: +13177 stage: -> patch review ___ Python tracker ___ ___

[issue36896] clarify in types.rst that FunctionTypes & co constructors don't have stable signature

New submission from Matthias Bussonnier : >From bpo-36886, IT is unclear the FunctionTypes, CodeTypes ... etc are not stable between python versions, and the recent addition of `:=` change some of the signatures. This suggest 2 things: - A CYA sentence in types.rst "These types are