[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Jeroen Demeyer added the comment: > IMHO the simplest and safest option for this issue is to revert tp_print > removal and move tp_vectorcall_offset at the end of PyTypeObject. I just realized that there is a much simpler solution: add back tp_print at the *end* of the PyTypeObject structure

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Change by Jeroen Demeyer : -- pull_requests: +14030 pull_request: https://github.com/python/cpython/pull/14193 ___ Python tracker ___ __

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Stefan Behnel added the comment: I agree with Steve that broadly redefining a global name in a widely used header file is not a good idea. You never know what names users have in their code. Yes, you can work around it by undef-ing it again, but honestly, in that case, both sides are hacks.

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Jeroen Demeyer added the comment: > This is a terrible idea, FWIW. Please don't do this. Why not? It's a simple pragmatic solution that fixes an actual problem at essentially no cost to CPython. You're right of course that Cython shouldn't set tp_print to 0 on Python 3. But I don't think th

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Steve Dower added the comment: > Any solution that we apply in Cython will require users to regenerate their > .c sources with a new Cython version in order to make it compile in Py3.8. > The main decision point in this ticket is: should they need to or not? Considering Cython had a bug when

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Stefan Behnel added the comment: (I forgot to state the obvious third option, which is: don't do anything and leave everything as it is now in beta-1.) -- ___ Python tracker

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Stefan Behnel added the comment: > they can equally easily zero out the entire structure and ignore it without > changing behavior on any Python 3.x. Any solution that we apply in Cython will require users to regenerate their .c sources with a new Cython version in order to make it compile i

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Steve Dower added the comment: > Jeroen Demeyer proposed PR 14009 to fix the source compatibility: > > #define tp_print tp_vectorcall This is a terrible idea, FWIW. Please don't do this. -- nosy: +ncoghlan ___ Python tracker

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Steve Dower added the comment: "tp_print" has been marked as reserved for all of Python 3. To me, that means deprecated and do not use. (But perhaps that ought to have been properly defined in the docs?) Cython should not be using this field directly. If all they're doing is setting it to N

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Jeroen Demeyer added the comment: > The two are related, no? Related in the same way that tp_dictoffset and tp_dict are related (i.e. not that much). -- ___ Python tracker _

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Jeroen Demeyer added the comment: > Honestly, reintroducing tp_print looks simple and safe enough. Is there any > drawback? 1. The one-time effort to change the code and documentation back. 2. Stefan Behnel wanted to use tp_print for backporting vectorcall in Cython to earlier Python versio

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

STINNER Victor added the comment: > Or maybe you're confusing tp_vectorcall_offset and tp_vectorcall again? The two are related, no? Honestly, reintroducing tp_print looks simple and safe enough. I'm in favor of doing that. Is there any drawback? (as I wrote, I don't think that the size of

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Jeroen Demeyer added the comment: > This code can cause subtle and annoying issue if PR 13858 is merged. Or maybe you're confusing tp_vectorcall_offset and tp_vectorcall again? -- ___ Python tracker ___

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Jeroen Demeyer added the comment: > If we decide to not reintroduce tp_print, tp_print removal must be documented > at: https://docs.python.org/dev/whatsnew/3.8.html#changes-in-the-c-api I'll add that to PR 13844. -- ___ Python tracker

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Jeroen Demeyer added the comment: > This code can cause subtle and annoying issue if PR 13858 is merged. I don't see how this is related to PR 13858 at all. Please explain. -- ___ Python tracker ___

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

STINNER Victor added the comment: https://github.com/cython/cython/commit/f10a0a391edef10bd37095af87f521808cb362f7 Note for myself: this fix is already part of Cython 0.29.10 released at June 2 (10 days ago). -- ___ Python tracker

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

STINNER Victor added the comment: me: > I understand that tp_vectorcall_offset=0 is fine and the expected value for a > type which doesn't have the flag _Py_TPFLAGS_HAVE_VECTORCALL. Jeroen Demeyer: > Not necessarily. There are subtleties involved when subclassing: there are > cases where tp_

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Jeroen Demeyer added the comment: > IMHO the simplest and safest option for this issue is to revert tp_print > removal and move tp_vectorcall_offset at the end of PyTypeObject. That's a drastic solution to a rather simple problem. PR 14009 would fix Cython just fine. -- ___

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

STINNER Victor added the comment: Cython issue: https://github.com/cython/cython/issues/2976 -- ___ Python tracker ___ ___ Python-b

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Jeroen Demeyer added the comment: > I understand that tp_vectorcall_offset=0 is fine and the expected value for a > type which doesn't have the flag _Py_TPFLAGS_HAVE_VECTORCALL. Not necessarily. There are subtleties involved when subclassing: there are cases where tp_vectorcall_offset needs

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

STINNER Victor added the comment: If we decide to not reintroduce tp_print, tp_print removal must be documented at: https://docs.python.org/dev/whatsnew/3.8.html#changes-in-the-c-api -- ___ Python tracker _

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

STINNER Victor added the comment: > No because tp_vectorcall is a function pointer. You're confusing with > tp_vectorcall_offset which is an integer. Oh. I didn't notice that your PR makes tp_print an alias to tp_vectorcall rather than tp_vectorcall_offset. Ok. -- _

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Change by STINNER Victor : -- nosy: +petr.viktorin, scoder ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

STINNER Victor added the comment: IMHO the simplest and safest option for this issue is to revert tp_print removal and move tp_vectorcall_offset at the end of PyTypeObject. Is PEP 590 fully public in Python 3.8? It seems like _Py_TPFLAGS_HAVE_VECTORCALL at least is private. Maybe we can att

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Jeroen Demeyer added the comment: > If -Werror is used, "type->tp_vectorcall = NULL;" would fail with a > compilation error, since NULL is not exactly an integer, no? No because tp_vectorcall is a function pointer. You're confusing with tp_vectorcall_offset which is an integer. --

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

STINNER Victor added the comment: inherit_slots() uses: /* Inherit tp_vectorcall_offset only if tp_call is not overridden */ if (!type->tp_call) { COPYSLOT(tp_vectorcall_offset); } PyType_Ready() contains the following assertion: /* Consistency checks

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Jeroen Demeyer added the comment: Actually, Cython generates code setting tp_print to 0 (not NULL). -- nosy: +jdemeyer ___ Python tracker ___ _

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

STINNER Victor added the comment: "printfunc tp_print;" has been replaced with "Py_ssize_t tp_vectorcall_offset;": the type was basically a pointer and has been replaced with an integer. With "#define tp_print tp_vectorcall", "type->tp_print = NULL;" becomes "type->tp_vectorcall = NULL;".

[issue37250] C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset

Change by STINNER Victor : -- title: C files generated by Cython set tp_print to NULL -> C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset ___ Python tracker

[issue37250] C files generated by Cython set tp_print to NULL

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +13880 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14009 ___ Python tracker ___ _

[issue37250] C files generated by Cython set tp_print to NULL

New submission from STINNER Victor : Copy of Stefan Behnel's msg345305 in bpo-37221: """ Note that PyCode_New() is not the only change in 3.8 beta1 that breaks Cython generated code. The renaming of "tp_print" to "tp_vectorcall" is equally disruptive, because Cython has (or had) a work-around