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.

> I would like some way of locally suppressing Py_DEPRECATED.

There was some discussion (and a pull request) on bpo-19569.

See also https://github.com/python/cpython/pull/14193#pullrequestreview-251630953

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

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"`.

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).

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

> We have some reserved/deprecated/unused fields.  Setting 0 to them makes forward incompatible code.

Good point. tp_print is removed in 3.9

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.

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.

> 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?

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

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.

>

I believe this to be a clang bug. I've filed an issue with upstream here: https://bugs.llvm.org/show_bug.cgi?id=45170