Missing PY_ prefixes in structmember.h
I'm sure this has a simple explanation (and is probably only of historical interest at this point), but ... While starting to port the Python Sybase module to Python 3, among other hurdles, I noticed that RO is no longer defined. Looking in structmember.h, I see that most of the macros defined there are missing a PY_ prefix. Given that these are macros which are likely to be used by extension modules and are thus really part of the C API, shouldn't they have PY_ or _PY_ prefixes? This file got its start in 1990, so would surely have been around for the great renaming <http://python-history.blogspot.com/2009/03/great-or-grand-renaming.html>. Looking at the documentation on defining new types, I saw no mention of these peculiarly named constants, though they are clearly documented. Thanks, Skip
2016-10-03 15:37 GMT+02:00 Skip Montanaro <skip.montanaro@gmail.com>:
While starting to port the Python Sybase module to Python 3, among other hurdles, I noticed that RO is no longer defined. Looking in structmember.h,
RO was an alias to READONLY. READONLY still exists in Python 3, just use this name. You might create an alias in your code if it is missing: #ifndef RO # define RO READONLY #endif Victor
Thanks, Victor, but that's not quite what I was asking. Replacing "RO" with "READONLY" is clearly no big deal. My question was more wondering why I didn't find myself replacing PY_RO with PY_READONLY". Both names were part of the Public API in the early 90s, I suspect, and one of that set of flags does have a "PY_" prefix. Why didn't these flags (and the T_* flags in structmember.h) get swept up in all the hubbub around the grand renaming. Skip On Mon, Oct 3, 2016 at 10:39 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
2016-10-03 15:37 GMT+02:00 Skip Montanaro <skip.montanaro@gmail.com>:
While starting to port the Python Sybase module to Python 3, among other hurdles, I noticed that RO is no longer defined. Looking in structmember.h,
RO was an alias to READONLY. READONLY still exists in Python 3, just use this name.
You might create an alias in your code if it is missing:
#ifndef RO # define RO READONLY #endif
Victor
Sounds like an oversight in a backwater of a header file. We should add the PY symbols and deprecate the others. --Guido (mobile) On Oct 3, 2016 10:17 AM, "Skip Montanaro" <skip.montanaro@gmail.com> wrote:
Thanks, Victor, but that's not quite what I was asking. Replacing "RO" with "READONLY" is clearly no big deal. My question was more wondering why I didn't find myself replacing PY_RO with PY_READONLY". Both names were part of the Public API in the early 90s, I suspect, and one of that set of flags does have a "PY_" prefix. Why didn't these flags (and the T_* flags in structmember.h) get swept up in all the hubbub around the grand renaming.
Skip
On Mon, Oct 3, 2016 at 10:39 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
2016-10-03 15:37 GMT+02:00 Skip Montanaro <skip.montanaro@gmail.com>:
While starting to port the Python Sybase module to Python 3, among other hurdles, I noticed that RO is no longer defined. Looking in structmember.h,
RO was an alias to READONLY. READONLY still exists in Python 3, just use this name.
You might create an alias in your code if it is missing:
#ifndef RO # define RO READONLY #endif
Victor
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/ guido%40python.org
hello Members, If any one is working AIML library for Python 3.5/3.6 version? Please let me know about it, thanks On Mon, Oct 3, 2016 at 10:50 PM, Guido van Rossum <gvanrossum@gmail.com> wrote:
Sounds like an oversight in a backwater of a header file. We should add the PY symbols and deprecate the others.
--Guido (mobile)
On Oct 3, 2016 10:17 AM, "Skip Montanaro" <skip.montanaro@gmail.com> wrote:
Thanks, Victor, but that's not quite what I was asking. Replacing "RO" with "READONLY" is clearly no big deal. My question was more wondering why I didn't find myself replacing PY_RO with PY_READONLY". Both names were part of the Public API in the early 90s, I suspect, and one of that set of flags does have a "PY_" prefix. Why didn't these flags (and the T_* flags in structmember.h) get swept up in all the hubbub around the grand renaming.
Skip
On Mon, Oct 3, 2016 at 10:39 AM, Victor Stinner <victor.stinner@gmail.com> wrote:
2016-10-03 15:37 GMT+02:00 Skip Montanaro <skip.montanaro@gmail.com>:
While starting to port the Python Sybase module to Python 3, among other hurdles, I noticed that RO is no longer defined. Looking in structmember.h,
RO was an alias to READONLY. READONLY still exists in Python 3, just use this name.
You might create an alias in your code if it is missing:
#ifndef RO # define RO READONLY #endif
Victor
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/guido% 40python.org
_______________________________________________ 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/ naitikchandak213%40gmail.com
On Mon, Oct 3, 2016 at 1:11 PM, Skip Montanaro <skip.montanaro@gmail.com> wrote:
Why didn't these flags (and the T_* flags in structmember.h) get swept up in all the hubbub around the grand renaming.
Note that structmember.h is semi-private - it is not included in Python.h. See discussion at <http://bugs.python.org/issue2897>.
But they most certainly are documented! So Skip's point is valid. MvL's suggestion for how to evolve this API is still the best IMO. On Mon, Oct 3, 2016 at 10:27 AM, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
On Mon, Oct 3, 2016 at 1:11 PM, Skip Montanaro <skip.montanaro@gmail.com> wrote:
Why didn't these flags (and the T_* flags in structmember.h) get swept up in all the hubbub around the grand renaming.
Note that structmember.h is semi-private - it is not included in Python.h. See discussion at <http://bugs.python.org/issue2897>.
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On 03.10.16 16:37, Skip Montanaro wrote:
I'm sure this has a simple explanation (and is probably only of historical interest at this point), but ...
While starting to port the Python Sybase module to Python 3, among other hurdles, I noticed that RO is no longer defined. Looking in structmember.h, I see that most of the macros defined there are missing a PY_ prefix. Given that these are macros which are likely to be used by extension modules and are thus really part of the C API, shouldn't they have PY_ or _PY_ prefixes? This file got its start in 1990, so would surely have been around for the great renaming <http://python-history.blogspot.com/2009/03/great-or-grand-renaming.html>. Looking at the documentation on defining new types, I saw no mention of these peculiarly named constants, though they are clearly documented.
structmember.h is not included in Python.h. I think it was not considered as the part of public C API. But PyMemberDef and constants are documented and structmember.h is used in C API examples. There are other problems with these constants. Opened an issue for this: http://bugs.python.org/issue28349 .
participants (7)
-
Alexander Belopolsky -
Guido van Rossum -
Guido van Rossum -
Naitik Chandak -
Serhiy Storchaka -
Skip Montanaro -
Victor Stinner