PyIndex_Check conflicts with PEP 384
Hi friends,
when implementing the limited API for PySide2, I recognized a little bug where a function was replaced by a macro.
The file number.rst on python 3.6 says
""" .. c:function:: int PyIndex_Check(PyObject *o)
Returns ``1`` if *o* is an index integer (has the nb_index slot of the tp_as_number structure filled in), and ``0`` otherwise. """
Without notice, this function was replaced by a macro a while ago, which reads
#define PyIndex_Check(obj) \ ((obj)->ob_type->tp_as_number != NULL && \ (obj)->ob_type->tp_as_number->nb_index != NULL)
This contradicts PEP 384, because there is no way for non-heaptype types to access the nb_index field.
If nobody objects, I would like to submit a patch that adds the function back when the limited API is active. I think to fix that before Python 3.7 is out.
Ciao -- Chris
Indeed, that sounds like a pretty straightforward bug in the stable ABI. You should file an issue on bugs.python.org so it doesn't get lost (and if it's the main new stable ABI break in 3.7 then you should probably mark that bug as a release blocker so that Ned notices it).
Unfortunately, very few people use the stable ABI currently, so it's easy for things like this to get missed. Hopefully it Qt starts using it then that will help us shake these things out... But it also means we need your help to catch these kinds of issues :-). Thanks!
On Fri, Jun 1, 2018, 06:51 Christian Tismer tismer@stackless.com wrote:
Hi friends,
when implementing the limited API for PySide2, I recognized a little bug where a function was replaced by a macro.
The file number.rst on python 3.6 says
""" .. c:function:: int PyIndex_Check(PyObject *o)
Returns ``1`` if *o* is an index integer (has the nb_index slot of the tp_as_number structure filled in), and ``0`` otherwise. """
Without notice, this function was replaced by a macro a while ago, which reads
#define PyIndex_Check(obj) \ ((obj)->ob_type->tp_as_number != NULL && \ (obj)->ob_type->tp_as_number->nb_index != NULL)
This contradicts PEP 384, because there is no way for non-heaptype types to access the nb_index field.
If nobody objects, I would like to submit a patch that adds the function back when the limited API is active. I think to fix that before Python 3.7 is out.
Ciao -- Chris
-- Christian Tismer-Sperling :^) tismer@stackless.com Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : http://pyside.org 14482 Potsdam : GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023
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/njs%40pobox.com
Hi Nate,
I just did that, and I got some follow-up work, too, which is fine with me. Just as a note for you:
Qt not itself, but PyQt5 did that already and submitted a stable ABI for Python 3.5 and up.
I was challenged end of last December to try that, and I succeeded after a long struggle, because I also needed to convert all of PySide2 to using heaptypes, and that was really hard. Actually, I succeeded yesterday, after 5 months. And now I know all the subtle things that people need to know when converting existing types to heaptypes.
Since QtC has adopted PySide2 in 2016, including myself as a consultant, now it is really a Qt product, and the limited API is due to my work. It comes naturally that I also should fix the problems which showed up during that process.
I also think to submit a paper to python.org where I document all the subtle problems which occured during the conversion process. It looks simple, but it really is not.
All the best -- Chris
On 01.06.18 17:18, Nathaniel Smith wrote:
Indeed, that sounds like a pretty straightforward bug in the stable ABI. You should file an issue on bugs.python.org http://bugs.python.org so it doesn't get lost (and if it's the main new stable ABI break in 3.7 then you should probably mark that bug as a release blocker so that Ned notices it).
Unfortunately, very few people use the stable ABI currently, so it's easy for things like this to get missed. Hopefully it Qt starts using it then that will help us shake these things out... But it also means we need your help to catch these kinds of issues :-). Thanks!
On Fri, Jun 1, 2018, 06:51 Christian Tismer <tismer@stackless.com mailto:tismer@stackless.com> wrote:
Hi friends, when implementing the limited API for PySide2, I recognized a little bug where a function was replaced by a macro. The file number.rst on python 3.6 says """ .. c:function:: int PyIndex_Check(PyObject *o) Returns ``1`` if *o* is an index integer (has the nb_index slot of the tp_as_number structure filled in), and ``0`` otherwise. """ Without notice, this function was replaced by a macro a while ago, which reads #define PyIndex_Check(obj) \ ((obj)->ob_type->tp_as_number != NULL && \ (obj)->ob_type->tp_as_number->nb_index != NULL) This contradicts PEP 384, because there is no way for non-heaptype types to access the nb_index field. If nobody objects, I would like to submit a patch that adds the function back when the limited API is active. I think to fix that before Python 3.7 is out. Ciao -- Chris -- Christian Tismer-Sperling :^) tismer@stackless.com <mailto:tismer@stackless.com> Software Consulting : http://www.stackless.com/ Karl-Liebknecht-Str. 121 : http://pyside.org 14482 Potsdam : GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023 _______________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/njs%40pobox.com
02.06.18 00:37, Christian Tismer пише:
I was challenged end of last December to try that, and I succeeded after a long struggle, because I also needed to convert all of PySide2 to using heaptypes, and that was really hard. Actually, I succeeded yesterday, after 5 months. And now I know all the subtle things that people need to know when converting existing types to heaptypes.
Are you aware of the following pitfall Christian?
participants (3)
-
Christian Tismer -
Nathaniel Smith -
Serhiy Storchaka