[issue29058] Mark new limited C API

Changes by Donald Stufft : -- pull_requests: +1090 ___ Python tracker ___ ___

[issue29058] Mark new limited C API

Changes by Serhiy Storchaka : -- status: open -> closed ___ Python tracker ___

[issue29058] Mark new limited C API

Steve Dower added the comment: I don't care enough to argue about it with you. Let's just fix the API as soon as we can and apologize to people who hit inconsistencies in earlier versions. -- ___ Python tracker

[issue29058] Mark new limited C API

Serhiy Storchaka added the comment: Do you suggest to emit a warning when the user just defines Py_LIMITED_API without specifying concrete version? #define Py_LIMITED_API I think this would break too much code. And contradicts to the documentation. If you mean something different, could

[issue29058] Mark new limited C API

Steve Dower added the comment: You've described it correctly. > The problem is that the warning should be emitted only for users that use > incorrect API. But it shouldn't be emitted for users that use just 3.2 API This is why I suggested #warn and not #error. It's okay to ignore warnings if

[issue29058] Mark new limited C API

Serhiy Storchaka added the comment: Sorry, but perhaps I don't fully understand you. It is legitimately to just define Py_LIMITED_API without requiring specific version: #define Py_LIMITED_API In that case you can use the stable API of the version 3.2, but can't use

[issue29058] Mark new limited C API

Steve Dower added the comment: > Just defining Py_LIMITED_API actually implies =0x0302. That's the intent, but if it were actually the case then this issue wouldn't exist :) On 3.5.3, building with Py_LIMITED_API=1 will include APIs that should only be included when

[issue29058] Mark new limited C API

Serhiy Storchaka added the comment: Just defining Py_LIMITED_API actually implies =0x0302. I have no idea where a #warn can be added. -- ___ Python tracker

[issue29058] Mark new limited C API

Steve Dower added the comment: Can we add a #warn to the headers then? So people know that just defining Py_LIMITED_API actually implies =0x0305 (or whatever value is appropriate)? -- ___ Python tracker

[issue29058] Mark new limited C API

Serhiy Storchaka added the comment: Changes are not applied to 3.5. It is harder to do since many private functions in 3.5 are still available in limited API. And there is a risk to break third-party code that defines Py_LIMITED_API, but uses API with higher version than required. --

[issue29058] Mark new limited C API

Roundup Robot added the comment: New changeset f26c16aba11e by Serhiy Storchaka in branch '3.6': Issue #29058: All stable API extensions added after Python 3.2 are now https://hg.python.org/cpython/rev/f26c16aba11e New changeset 77f5f31bf699 by Serhiy Storchaka in branch 'default': Issue

[issue29058] Mark new limited C API

Serhiy Storchaka added the comment: Updated patch removes PyODict_HasKey() at all, removes PyODict_Check(), PyODict_CheckExact(), PyODict_SIZE() and Py_hexdigits from stable API. -- Added file: http://bugs.python.org/file46044/limited-api-2.patch

[issue29058] Mark new limited C API

Serhiy Storchaka added the comment: Actually PyODict_Check, PyODict_CheckExact, and PyODict_SIZE should be excluded from limited API. These macros are expanded to the code that don't work with limited API (needed PyODict_Type and PyDictObject). PyODict_HasKey is expanded to syntactically

[issue29058] Mark new limited C API

Steve Dower added the comment: Those changes all look good to me, though it's a shame we can't leave some of those functions out altogether. -- nosy: +steve.dower ___ Python tracker

[issue29058] Mark new limited C API

New submission from Serhiy Storchaka: Functions added to a limited API after 3.2 should be available only when Py_LIMITED_API is not defined or is set to corresponding hexadecimal Python version (e.g. 0x0305). Proposed patch makes following names available only for corresponding versions