classification
Title: Py_DEPRECATED and unavoidable warnings
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: ZackerySpytz, inada.naoki, jdemeyer, philthompson10
Priority: normal Keywords: patch

Created on 2019-07-13 17:53 by philthompson10, last changed 2019-07-19 13:26 by inada.naoki.

Files
File name Uploaded Description Edit
pyport.h.diff philthompson10, 2019-07-13 17:53
Messages (13)
msg347848 - (view) Author: Phil Thompson (philthompson10) Date: 2019-07-13 17:53
I have a number of static PyTypeObject declarations. In order to avoid compiler warnings about missing field initialisers I always provide explicit 0 values for unused fields (protected by #if PY_HEX_VERSION >= ...). However with v3.8b2 this triggers new warnings from Py_DEPRECATED because of the initialiser for tp_print.

I would like some way of locally suppressing Py_DEPRECATED. The attached trivial patch would do this by allowing me to define a null Py_DEPRECATED before including Python.h.
msg347910 - (view) Author: Zackery Spytz (ZackerySpytz) * (Python triager) Date: 2019-07-14 13:10
> I would like some way of locally suppressing Py_DEPRECATED.

There was some discussion (and a pull request) on bpo-19569.
msg347950 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2019-07-15 08:19
See also https://github.com/python/cpython/pull/14193#pullrequestreview-251630953
msg348050 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2019-07-17 08:17
One possible solution would be to have a macro to suppress the tp_print field in the first place. Something like

#ifndef PY_NO_TP_PRINT
    /* bpo-37250: kept for backwards compatibility in CPython 3.8 only */
    Py_DEPRECATED(3.8) int (*tp_print)(PyObject *, FILE *, int);
#endif
msg348152 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2019-07-19 08:05
I think it's bad idea that suppressing deprecation warning to suppress the warning for deprecated member.

It is highly recommended to "not" touching tp_print.
Why you want to suppress deprecation warning, not missing field initialisers?

You can suppress the warninb by `-Wno-missing-field-initializers` compiler option or `#pragma GCC diagnostic ignored "-Wmissing-field-initializers"`.
msg348159 - (view) Author: Phil Thompson (philthompson10) Date: 2019-07-19 09:35
I am not "touching" tp_print. I am simply defining it as 0 to avoid the missing initialiser warning. My point is that it should be possible to write code that doesn't trigger warnings (whether or not you suppress them).
msg348162 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2019-07-19 09:50
> I am not "touching" tp_print. I am simply defining it as 0 to avoid the missing initialiser warning.

I meant it.  `tp_print = 0` touches the deprecated `tp_print` field.
It is not forward compatible.  Note that we need to re-add tp_print only for C code which does `tp_print = 0`.


>  My point is that it should be possible to write code that doesn't trigger warnings (whether or not you suppress them).

There is a simple solution: don't use `-Wextra`.

We have some reserved/deprecated/unused fields.  Setting 0 to them makes forward incompatible code.  It bothers us to remove or reuse these fields.

There are some other solutions, suppress the missing initializer warning as I wrote above, or use PyType_FromSpec instead of static type.
msg348163 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2019-07-19 10:37
> We have some reserved/deprecated/unused fields.  Setting 0 to them makes forward incompatible code.

Good point. tp_print is removed in 3.9
msg348166 - (view) Author: Phil Thompson (philthompson10) Date: 2019-07-19 11:47
On 19/07/2019 11:37, Jeroen Demeyer wrote:
> Jeroen Demeyer <J.Demeyer@UGent.be> added the comment:
> 
>> We have some reserved/deprecated/unused fields.  Setting 0 to them 
>> makes forward incompatible code.
> 
> Good point. tp_print is removed in 3.9

Which is why I protect the initialisation with #if PY_VERSION_HEX < 
0x03090000

As far as I can see this is the "right thing" to do. However doing the 
"right thing" means I cannot avoid warnings without resorting to 
compiler-specific build system changes.

With the change I am asking for I can suppress the warning (because I 
have explicitly dealt with the issue) in the code itself without 
affecting the rest of the system.
msg348169 - (view) Author: Jeroen Demeyer (jdemeyer) * (Python triager) Date: 2019-07-19 11:59
I support the patch proposed in https://bugs.python.org/file48478/pyport.h.diff but it's not up to me to make that decision.
msg348170 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2019-07-19 12:07
> Which is why I protect the initialisation with #if PY_VERSION_HEX < 
0x03090000

It is your specific case.  We can not assume people do it, or even you never forget it.  So this is not the "right thing" we can recommend to all users.

Once you or other people suppress the deprecation warning and forget the protect, compatibility issue happen again.  Why such dangerous option is needed?


Note that we don't use `-Wextra` or `-Wmissing-field-initializers`.  The missing initializer warning is specific to you.  You manually enabled the warning.

So why should we provide the way to suppress the warning we never recommend to enable?
msg348172 - (view) Author: Phil Thompson (philthompson10) Date: 2019-07-19 13:00
>> Which is why I protect the initialisation with #if PY_VERSION_HEX <
> 0x03090000
> 
> It is your specific case.  We can not assume people do it, or even you
> never forget it.  So this is not the "right thing" we can recommend to
> all users.
> 
> Once you or other people suppress the deprecation warning and forget
> the protect, compatibility issue happen again.  Why such dangerous
> option is needed?

If I fail to protect against using a feature when it is no longer 
present then it's a bug in my code and it won't compile. Providing a 
deprecation warning gives me some notice that my code needs to be 
changed. That is helpful but not strictly necessary as I will soon find 
out when testing against the new version. There is nothing "dangerous" 
here.
msg348174 - (view) Author: Inada Naoki (inada.naoki) * (Python committer) Date: 2019-07-19 13:26
2019年7月19日(金) 22:00 Phil Thompson <report@bugs.python.org>:

>
> If I fail to protect against using a feature when it is no longer
> present then it's a bug in my code and it won't compile. Providing a
> deprecation warning gives me some notice that my code needs to be
> changed. That is helpful but not strictly necessary as I will soon find
> out when testing against the new version. There is nothing "dangerous"
> here.
>

You are proposing to change Python, so it's not only your option.  It may
be safe for you, but may be not safe for all authors who creating extension
and share it on PyPI.

If it's only your problem, you can manually suppress the warning, like you
manually enabled missing initializer warning.  No need to add an option to
CPython.

>
History
Date User Action Args
2019-07-19 13:26:04inada.naokisetmessages: + msg348174
2019-07-19 13:00:02philthompson10setmessages: + msg348172
2019-07-19 12:07:57inada.naokisetmessages: + msg348170
2019-07-19 11:59:50jdemeyersetmessages: + msg348169
2019-07-19 11:47:12philthompson10setmessages: + msg348166
2019-07-19 10:37:32jdemeyersetmessages: + msg348163
2019-07-19 09:50:40inada.naokisetmessages: + msg348162
2019-07-19 09:35:50philthompson10setmessages: + msg348159
2019-07-19 08:05:35inada.naokisetnosy: + inada.naoki
messages: + msg348152
2019-07-17 08:17:50jdemeyersetmessages: + msg348050
2019-07-15 08:19:58jdemeyersetnosy: + jdemeyer
messages: + msg347950
2019-07-14 13:10:33ZackerySpytzsetnosy: + ZackerySpytz
messages: + msg347910
2019-07-13 17:53:56philthompson10create