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@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/stephane%40wirtel.be > _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com