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
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 .
-
Alexander Belopolsky -
Guido van Rossum -
Guido van Rossum -
Naitik Chandak -
Serhiy Storchaka -
Skip Montanaro -
Victor Stinner