[3.8] bpo-37250: put back tp_print for backwards compatibility #14193
Conversation
|
+1, but let's refrain from merging until there's clearer consensus on the tracker issue for the pragmatic Py3.8-only source compatibility fix. |
Include/cpython/object.h
Outdated
| @@ -256,6 +256,9 @@ typedef struct _typeobject { | |||
| destructor tp_finalize; | |||
| vectorcallfunc tp_vectorcall; | |||
|
|
|||
| /* Unused, kept for backwards compatibility in CPython 3.8 only */ | |||
| int (*tp_print)(PyObject *, FILE *, int); | |||
There was a problem hiding this comment.
Does adding the Py_DEPRECATED(3.8) macro here cause the tp_print reference in the test to generate a compiler warning?
If it does, that would be a good thing to add (as long as we also have a way to disable the deprecation warning in the test suite, which I presume we do)
Reference: https://docs.python.org/3.8/c-api/intro.html#c.Py_DEPRECATED
There was a problem hiding this comment.
That works but then the deprecation warning will be shown when compiling _testcapi.c. I'll add a guard for that. If that's controversial, I'll gladly remove it.
(off-topic: since this is the only such warning shown, it seems that we never actually test deprecated functionality of the C API, which is worrying)
Include/cpython/object.h
Outdated
| @@ -256,6 +256,9 @@ typedef struct _typeobject { | |||
| destructor tp_finalize; | |||
| vectorcallfunc tp_vectorcall; | |||
|
|
|||
| /* Unused, kept for backwards compatibility in CPython 3.8 only */ | |||
There was a problem hiding this comment.
Please mention that it will be removed from Python 3.8. You may add "bpo-37250: " prefix.
Include/pyport.h
Outdated
| @@ -510,6 +510,7 @@ extern "C" { | |||
| * Py_DEPRECATED(3.4) typedef int T1; | |||
| * Py_DEPRECATED(3.8) PyAPI_FUNC(int) Py_OldFunction(void); | |||
| */ | |||
| #ifndef Py_DEPRECATED | |||
There was a problem hiding this comment.
IMHO it's fine if compiling _testcapimodule.c emits a deprecation warning. If it becomes an issue, we can just remove the test.
There was a problem hiding this comment.
IMHO it's fine if compiling _testcapimodule.c emits a deprecation warning.
The more warnings are shown, the less value there is in those warnings. A single warning during compilation stands out, an additional warning in between many not. So we should strive for compiling CPython without any warnings.
If it becomes an issue, we can just remove the test.
I think that's the worst solution. We typically test deprecated functionality in pure Python modules, why shouldn't we test deprecated C API?
There was a problem hiding this comment.
Reading https://stackoverflow.com/questions/13459602/how-can-i-get-rid-of-deprecated-warnings-in-deprecated-functions-in-gcc/ suggests there are a few ways we can go here:
- Mark the _testcapi init function itself as deprecated, so compilers won't care that it accesses deprecated symbols.
- Start defining compiler specific
_Py_PUSH_PRAGMA_IGNORE_DEPRECATION_WARNINGSand_Py_POP_PRAGMAmacros and use those to selectively silence compiler warnings - Use the testcapi warnings to check that deprecated C APIs actually are deprecated (doing that long term might involve pulling out a separately compiled module for those though, so we can more easily distinguish them from actual warnings in the main interpreter and standard library build process)
For right now, I'd suggest seeing if the warning goes away if you mark the testcapi module's init function as deprecated.
|
Will do. Thanks to everyone involved! |
PR for 3.8 only, since this is supposed to be a temporary compatibility measure.
https://bugs.python.org/issue37250