[issue37588] Py_DEPRECATED and unavoidable warnings

Change by Irit Katriel : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue37588] Py_DEPRECATED and unavoidable warnings

Ben Boeckel added the comment: 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 -- nosy: +mathstuf ___ Python tracker

[issue37588] Py_DEPRECATED and unavoidable warnings

Inada Naoki added the comment: 2019年7月19日(金) 22:00 Phil Thompson : > > 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

[issue37588] Py_DEPRECATED and unavoidable warnings

Phil Thompson added the comment: >> Which is why I protect the initialisation with #if PY_VERSION_HEX < > 0x0309 > > 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

[issue37588] Py_DEPRECATED and unavoidable warnings

Inada Naoki added the comment: > Which is why I protect the initialisation with #if PY_VERSION_HEX < 0x0309 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

[issue37588] Py_DEPRECATED and unavoidable warnings

Jeroen Demeyer added the comment: 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. -- ___ Python tracker

[issue37588] Py_DEPRECATED and unavoidable warnings

Phil Thompson added the comment: On 19/07/2019 11:37, Jeroen Demeyer wrote: > Jeroen Demeyer 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

[issue37588] Py_DEPRECATED and unavoidable warnings

Jeroen Demeyer 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 -- ___ Python tracker

[issue37588] Py_DEPRECATED and unavoidable warnings

Inada Naoki added the comment: > 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

[issue37588] Py_DEPRECATED and unavoidable warnings

Phil Thompson added the comment: 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). --

[issue37588] Py_DEPRECATED and unavoidable warnings

Inada Naoki added the comment: 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

[issue37588] Py_DEPRECATED and unavoidable warnings

Jeroen Demeyer added the comment: 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

[issue37588] Py_DEPRECATED and unavoidable warnings

Jeroen Demeyer added the comment: See also https://github.com/python/cpython/pull/14193#pullrequestreview-251630953 -- nosy: +jdemeyer ___ Python tracker ___

[issue37588] Py_DEPRECATED and unavoidable warnings

Zackery Spytz added the comment: > I would like some way of locally suppressing Py_DEPRECATED. There was some discussion (and a pull request) on bpo-19569. -- nosy: +ZackerySpytz ___ Python tracker

[issue37588] Py_DEPRECATED and unavoidable warnings

New submission from Phil Thompson : 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