[issue29058] Mark new limited C API

2017-03-31 Thread Donald Stufft

Changes by Donald Stufft :


--
pull_requests: +1090

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2017-01-22 Thread Serhiy Storchaka

Changes by Serhiy Storchaka :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2017-01-22 Thread Steve Dower

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2017-01-22 Thread Serhiy Storchaka

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 you provide a patch?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2016-12-27 Thread Steve Dower

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 
you know what you're doing, but if there's no warning then people who don't 
know what they're doing will get it wrong. We know that some people are subtly 
broken here, and ought to tell them.

Further, if we make the warning only appear for "defined(Py_LIMITED_API) && 
Py_LIMITED_API+0<0x0300" then the warning can be suppressed by setting the 
exact version you intend to use (even though this doesn't prevent you from 
using the incorrect functions).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2016-12-27 Thread Serhiy Storchaka

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 
PyType_FromSpecWithBases() and PyModule_AddFunctions(), because they are 
correctly attributed as API of versions 3.3 and 3.5. You can also mistakenly 
use PyImport_ImportModuleLevelObject() added in 3.5, this is a matter of this 
issue. But you shouldn't.

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 
(perhaps the code was written at the time of 3.2 and was not changed since).

--
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2016-12-27 Thread Steve Dower

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 Py_LIMITED_API=0x0305. You considered fixing that too likely 
to break existing users (and I agree), but that doesn't mean we shouldn't make 
it clear that it's not doing exactly the right thing.

> I have no idea where a #warn can be added.

pyport.h or pymacro.h are probably the best places. If you null-merge into 3.6 
then we shouldn't have to worry about the warning showing up in later versions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2016-12-27 Thread Serhiy Storchaka

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2016-12-27 Thread Steve Dower

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2016-12-27 Thread Serhiy Storchaka

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.

--
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2016-12-27 Thread Roundup Robot

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 #29058: All stable API extensions added after Python 3.2 are now
https://hg.python.org/cpython/rev/77f5f31bf699

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2016-12-26 Thread Serhiy Storchaka

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2016-12-25 Thread Serhiy Storchaka

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 invalid code.

--
nosy: +eric.snow

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2016-12-25 Thread Steve Dower

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29058] Mark new limited C API

2016-12-23 Thread Serhiy Storchaka

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 
of a limited API.

Removed declaration: PyErr_SetExcWithArgsKwargs().

Excluded from stable ABI: _PyBytes_DecodeEscape(), PyInit_imp().

3.3: Py_hexdigits, PyImport_ExecCodeModuleObject(), PyImport_AddModuleObject(), 
PyImport_ImportFrozenModuleObject(), PyMemoryView_FromMemory(), 
PyModule_NewObject(), PyModule_GetNameObject(), PyObject_GenericSetDict(), 
PyErr_GetExcInfo(), PyErr_SetExcInfo(), PyErr_SetImportError(), 
PyParser_SimpleParseStringFlagsFilename(), PyThread_GetInfo(), 
PyUnicode_Substring(), PyUnicode_AsUCS4(), PyUnicode_AsUCS4Copy(), 
PyUnicode_GetLength(), PyUnicode_ReadChar(), PyUnicode_WriteChar(), 
PyUnicode_DecodeCodePageStateful(), PyUnicode_EncodeCodePage(), 
PyUnicode_DecodeLocaleAndSize(), PyUnicode_DecodeLocale(), 
PyUnicode_EncodeLocale(), PyUnicode_FindChar(), and a number of OSError 
subclasses.

3.4: PyErr_SetFromErrnoWithFilenameObjects(), 
PyErr_SetExcFromWindowsErrWithFilenameObjects().

3.5: PyNumber_MatrixMultiply(), PyNumber_InPlaceMatrixMultiply(), 
PyCodec_NameReplaceErrors(), Py_DecodeLocale(), Py_EncodeLocale(), 
PyImport_ImportModuleLevelObject(), PyObject_Calloc(), 
PyExc_StopAsyncIteration, PyExc_RecursionError, PyMem_Calloc(), 
a number of PyODict_* macros.

3.6: Py_FileSystemDefaultEncodeErrors, PyOS_FSPath(), 
PyExc_ModuleNotFoundError, PyErr_SetImportErrorSubclass(), 
PyErr_ResourceWarning().

However it may be better that some was added to stable ABI by mistake. 
Py_hexdigits looks as a stuff for internal use, PyThread_GetInfo() and 
PyODict_* macros are not documented.

--
components: Interpreter Core
files: limited-api.patch
keywords: patch
messages: 283910
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Mark new limited C API
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46016/limited-api.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com