[Python-Dev] introduction of __attribute__(deprecated) ?

[Stéphane Wirtel]

And use an enumeration for the constants.

For example:

#include <stdio.h>
#include <stdlib.h>

enum {
    PY_READWRITE = 0,
    PY_READONLY = 1,

    READONLY __attribute((deprecated("use PY_READONLY"))) = PY_READONLY,
    READWRITE __attribute((deprecated("use PY_READWRITE"))) = PY_READWRITE,
};



Le 24/03/19 à 20:52, Stéphane Wirtel a écrit :
> Hi,
> 
> I have created the issue https://bugs.python.org/issue36347 because I
> wanted to add a missing macro for the PyMemberDef.flags attribute.
> 
> In the Modules/*.c files, we can find descriptions with
> PyMemberDef where the access flag has the 0 value.
> 
> Example:
> 
> static PyMemberDef members[] = {
>     {"name", T_OBJECT, offsetof(MyObject, name), 0, NULL},
>     {NULL},
> };
> 
> So, I didn't know the meaning of this magic number (0) and after a small
> search in structmember.h, this is the default value for an "READWRITE"
> attribute but there is no associated macro to this magic number.
> 
> solution: add the macro for the READWRITE mode.
> 
> so, my first PR has added the new macro READWRITE, like that
> 
> #define READWRITE 0
> 
> and improve the documentation in Doc/c-api/structures.rst.
> 
> but after a review [1], Serhiy proposed to rename it and the other ones
> because it did not follow the convention for names in the C API.
> Use a prefix for the public names, example Py_ or PY_.
> 
> I chose PY_ because PY_WRITE_RESTRICTED already existed.
> 
> the next steps were:
> * add the new macros
> * keep the backward-compatibility
> * updated the documentation
> 
> I haved pushed the PR for another review
> 
> so, but I don't like this definition of READONLY because there is no way
> to generate a warning at the compile time when we use the READONLY macro.
> 
> #define PY_READONLY	0
> #define READONLY 	PY_READONLY
> 
> after that, I have closed my PR because I was not proud with my "solution".
> 
> 
> Today, Ronald Oussoren [2] has proposed an other solution based on an
> enum and a new __attribute__, aka deprecated.
> 
> I have checked with gcc and clang and this option is interesting because
> we generate a warning when we try to compile a code if we use the
> deprecated READONLY [3]
> 
> In the clang documantion, the __attribute__(deprecated) is defined in
> GNU and C++11 standard, like __attribute__(unused).
> 
> In the gcc documentation, this attribute also exists
> 
> Because we already use __attribute__(unused) we could add
> __attribute__(deprecated).
> 
> 
> LC_ALL=C clang test.c -o test
> test.c:14:13: warning: 'READONLY' is deprecated: use PY_READONLY
> [-Wdeprecated-declarations]
>     int i = READONLY;
>             ^
> test.c:8:27: note: 'READONLY' has been explicitly marked deprecated here
>     READONLY __attribute((deprecated("use PY_READONLY"))) = PY_READONLY,
>                           ^
> 1 warning generated.
> 
> LC_ALL=C clang --version test.c -o test
> clang version 7.0.1 (Fedora 7.0.1-6.fc29)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
> 
> ### GCC
> LC_ALL=C gcc --version test.c -o test
> gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> LC_ALL=C gcc test.c -o test
> test.c: In function 'main':
> test.c:14:5: warning: 'READONLY' is deprecated: use PY_READONLY
> [-Wdeprecated-declarations]
>      int i = READONLY;
>      ^~~
> test.c:8:5: note: declared here
>      READONLY __attribute((deprecated("use PY_READONLY"))) = PY_READONLY,
>      ^~~~~~~~
> 
> So my question is, can we use/add __attribute__(deprecated) in our
> "development" kit?
> 
> [1] https://bugs.python.org/issue36347#msg338261
> [2] https://bugs.python.org/issue36347#msg338731
> [3] https://bugs.python.org/issue36347#msg338745
> 
> Thank you,
> 
> Stéphane
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/stephane%40wirtel.be
>