classification
Title: C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
Type: Stage: patch review
Components: Interpreter Core Versions: Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: jdemeyer, ncoghlan, petr.viktorin, scoder, steve.dower, vstinner
Priority: normal Keywords: patch

Created on 2019-06-12 13:08 by vstinner, last changed 2019-06-18 22:33 by ncoghlan.

Pull Requests
URL Status Linked Edit
PR 14009 closed jdemeyer, 2019-06-12 13:10
PR 14193 open jdemeyer, 2019-06-18 08:50
Messages (37)
msg345337 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-12 13:08
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 for CPython (mis-)behaviour that reset the field explicitly to NULL after calling PyType_Ready(), which could set it arbitrarily without good reason.

So, either revert that field renaming, too, or ignore Cython generated modules for the reasoning about the change in this ticket.

I'm fine with keeping things as they are now in beta-1, but we could obviously adapt to whatever beta-2 wants to change again.
"""

There are 2 problems:

* source compatibility
* ABI compatibility

The following change removed PyTypeObject.tp_print and replaced it with PyTypeObject.tp_vectorcall_offset:

commit aacc77fbd77640a8f03638216fa09372cc21673d
Author: Jeroen Demeyer <J.Demeyer@UGent.be>
Date:   Wed May 29 20:31:52 2019 +0200

    bpo-36974: implement PEP 590 (GH-13185)
    
    
    Co-authored-by: Jeroen Demeyer <J.Demeyer@UGent.be>
    Co-authored-by: Mark Shannon <mark@hotpy.org>


== ABI compatibility ==

In term of ABI, it means that C extensions using static type ("static PyTypeObject mytype = { .... };") is broken by this change.

Honestly, I'm not sure if we ever provided any forward compatibility for static types. bpo-32388 removed "cross-version binary compatibility" on purpose in Python 3.8. It's an on-going topic, see also my notes about ABI and PyTypeObject:
https://pythoncapi.readthedocs.io/type_object.html

Maybe we can simply ignore this part of the problem.


== Source compatibility ==

Cython generates C code setting tp_print explicitly to NULL.

To avoid depending on Cython at installation, most (if not all) projects using Cython include C files generated by Cython in files they distribute (like tarballs). Because of that, the commit aacc77fbd77640a8f03638216fa09372cc21673d requires all these projects to regenerate their C files using Cython.

In Fedora, we fixed many Python packages to always re-run Cython to regenerate all C files. But Fedora is just one way to distribute packages, it doesn't solve the problem of files distributed on PyPI, nor other Linux distribution (for example).

Jeroen Demeyer proposed PR 14009 to fix the source compatibility:

   #define tp_print tp_vectorcall
msg345340 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-12 13:17
"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;".

If -Werror is used, "type->tp_vectorcall = NULL;" would fail with a compilation error, since NULL is not exactly an integer, no? I'm not sure that it's an issue, I'm just thinking aloud.
msg345341 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-12 13:20
Actually, Cython generates code setting tp_print to 0 (not NULL).
msg345342 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-12 13:21
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 for PEP 590:
     * - Py_TPFLAGS_METHOD_DESCRIPTOR requires tp_descr_get
     * - _Py_TPFLAGS_HAVE_VECTORCALL requires tp_call and
     *   tp_vectorcall_offset > 0
     * To avoid mistakes, we require this before inheriting.
     */
    if (type->tp_flags & Py_TPFLAGS_METHOD_DESCRIPTOR) {
        _PyObject_ASSERT((PyObject *)type, type->tp_descr_get != NULL);
    }
    if (type->tp_flags & _Py_TPFLAGS_HAVE_VECTORCALL) {
        _PyObject_ASSERT((PyObject *)type, type->tp_vectorcall_offset > 0);
        _PyObject_ASSERT((PyObject *)type, type->tp_call != NULL);
    }

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.
msg345343 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-12 13:24
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 attempt again to remove tp_print from Python 3.9? Once Cython will handle tp_print removal? Or even keep it in Python 3.9?

Python 3 had unused tp_print for 10 years and nobody complained. There are a few PyTypeObject instances in a Python process. A single pointer isn't a giant waste of memory.
msg345344 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-12 13:24
> 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.
msg345345 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-12 13:28
> 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.
msg345346 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-12 13:29
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
msg345347 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-12 13:31
> 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 to be non-zero despite _Py_TPFLAGS_HAVE_VECTORCALL not being set. See also PR 13858.
msg345348 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-12 13:32
Cython issue: https://github.com/cython/cython/issues/2976
msg345349 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-12 13:35
> 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.
msg345350 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-12 13:36
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_vectorcall_offset needs to be non-zero despite _Py_TPFLAGS_HAVE_VECTORCALL not being set. See also PR 13858.

Cython generates C code which looks like:

if (PyType_Ready(type) < 0) { ... handle error ... }
type->tp_print = 0;

This code can cause subtle and annoying issue if PR 13858 is merged. So that's another argument in favor of reintroducing tp_print in Python 3.8.

--

Cython has already been fixed to no longer set tp_print to 0 on Python 3.8:

https://github.com/cython/cython/commit/f10a0a391edef10bd37095af87f521808cb362f7

But again, this problem is not about correctness, but more about practical backward compatibility issues (see my first message).
msg345351 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-12 13:38
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).
msg345352 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-12 13:39
> 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.
msg345353 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-12 13:40
> 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.
msg345355 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-12 13:41
> 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?
msg345356 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-12 13:47
> 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 PyTypeObject really matters in practice)
msg345357 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-12 13:57
> 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 versions.

3. Stable ABI incompatibility (the complaint that you incorrectly added to PR 13858 would become correct).
msg345359 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-12 14:00
> The two are related, no?

Related in the same way that tp_dictoffset and tp_dict are related (i.e. not that much).
msg345382 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-06-12 17:04
"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 NULL, they can equally easily zero out the entire structure and ignore it without changing behavior on any Python 3.x.

I have no problem changing the names of deprecated/reserved fields in PyTypeObject between releases. Source compatibility guarantees do not extend that far.
msg345383 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-06-12 17:06
> 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.
msg345402 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2019-06-12 18:48
> 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 in Py3.8. The main decision point in this ticket is: should they need to or not? Everything else is just minor technicalities. (I didn't bring up this topic, but the question is up on the table now.)


> I have no problem changing the names of deprecated/reserved fields in PyTypeObject between releases. Source compatibility guarantees do not extend that far.

Fair enough, and I'm ok with letting CPython move forward cleanly and break things that are easily fixed on user side.

My point is that it makes no sense to justify bpo-37221 with the goal of not breaking Cython modules, when at the same time another change (the one discussed here) has already broken them. Either we find a striking justification for bpo-37221 that *excludes* Cython generated modules, or we take back *both* changes and restore full source code compatibility. Everything in between is just causing useless code churn and annoyance on all sides.
msg345405 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2019-06-12 20:26
(I forgot to state the obvious third option, which is: don't do anything and leave everything as it is now in beta-1.)
msg345409 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-06-12 21:18
> 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 it generated those sources (directly using a reserved field), then yes, users should have to regenerate with a fixed version.

> My point is that it makes no sense to justify bpo-37221 with the goal of not breaking Cython modules, when at the same time another change (the one discussed here) has already broken them.

I agree. Here's my distinction:

bpo-37221 breaks any user who correctly followed the documentation: https://docs.python.org/3.7/c-api/code.html#c.PyCode_New

This issue breaks users who did not follow the documentation: https://docs.python.org/3.7/c-api/typeobj.html#c.PyTypeObject.tp_print
msg345459 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-13 06:46
> 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 that's a relevant argument.
msg345591 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2019-06-14 12:26
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.
msg345965 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-18 08:51
> 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. This will fix the Cython problem and is even less likely to break stuff. I'm doing that in PR 14193.
msg345966 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-18 08:52
> I just realized that there is a much simpler solution: add back tp_print at the *end* of the PyTypeObject structure. This will fix the Cython problem and is even less likely to break stuff. I'm doing that in PR 14193.

If we reintroduce it, why not put it back at its previous place, to provide ABI compatibility?
msg345969 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-18 09:07
> If we reintroduce it, why not put it back at its previous place, to provide ABI compatibility?

First of all, we longer care about ABI compatibility of PyTypeObject.

Second, it is extremely unlikely that the class will use vectorcall: the only way would be to inherit from a base class that uses vectorcall, but there aren't any subclassable classes using vectorcall in CPython. If the class doesn't use vectorcall, then it really doesn't matter: tp_vectorcall_offset is unused in that case, just like tp_print.
msg345988 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-06-18 15:16
> If we reintroduce it, why not put it back at its previous place, to provide ABI compatibility?

I agree. If compatibility matters here, then we should add new elements at the end.

> First of all, we longer care about ABI compatibility of PyTypeObject.

Oh? In that case, let's just remove the reserved/deprecated field :)

> Second, it is extremely unlikely ...

As a rule, "extremely unlikely" isn't unlikely enough for a product with as much reach as Python has. Even if something only happens to 0.1% of users, that's still thousands of people. You have to be prepared to justify hurting those people - potentially to their faces - to back up ideas like this. (And FWIW, yes, I'm happy to explain to people that their pre-generated Cython code broke because Cython had a bug that has since been fixed.)
msg345989 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-18 15:22
> Oh? In that case, let's just remove the reserved/deprecated field :)

Don't confuse *ABI* and *API* compatibility. For *API* compatibility, it doesn't matter where we put tp_print.
msg345990 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-06-18 15:44
> Don't confuse *ABI* and *API* compatibility. For *API* compatibility, it doesn't matter where we put tp_print.

Don't worry, I'm not. (Though I did blur the lines for the sake of a tongue-in-cheek reply to your comment. Probably shouldn't do that in text with people I haven't spent time with in real life :) )

We're not making any progress here, so perhaps it's time to escalate the decision to the steering council. My read of it:

* Python 3.8 removed a deprecated struct member
* Cython prior to 0.29.10 was writing directly to this member to clear it
* any sdists that include pregenerated Cython modules will fail to build against 3.8

Things to decide (beyond this one-off case):
* are deprecated struct members allowed to be removed in new major version?
* should Cython (using non-stable API) be expected to make updates for new major CPython versions?
* should we treat pre-generated Cython .c files with the same compatibility constraints we use for hand-written C code

My view is yes, yes and no.
* If a field has been deprecated for the normal amount of time and is not in the stable API, it can be removed.
* Cython does not use the stable API, and so should expect to make changes when a new major version of CPython is released
* Pre-generated Cython .c files can be easily regenerated, and given their use of low-level and internal APIs would cause undue compatibility burden on CPython if we were to treat everything it uses as public stable API
msg345992 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-18 15:55
I would argue for the pragmatic solution: PR 14193 fixes that old Cython-generated code. More generally, it fixes API compatibility and doesn't make ABI compatibility worse than the status quo (the proposal of putting back tp_print in place of tp_vectorcall_offset does).

Of course, it may not fix every single use case, but even if we can't fix that hypothetical 0.1%, we can still fix the 99.9%.

The proposed fix is very small and only applied to 3.8, so there is no long-term maintenance burden. So the obvious question: why not? What's wrong with PR 14193?
msg345994 - (view) Author: Jeroen Demeyer (jdemeyer) * Date: 2019-06-18 16:05
Personally, I don't think that your "read of it" in #msg345990 is relevant to the discussion of the PR (I don't mean this in a bad way).

It's one thing to say "we're not obliged to fix this" (I agree with that) but that doesn't imply that it's forbidden to fix the issue and that we should automatically reject proposed fixes.
msg345996 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2019-06-18 16:12
> Personally, I don't think that your "read of it" in #msg345990 is relevant to the discussion of the PR (I don't mean this in a bad way).

It's relevant to the *existence* of the PR, because when you follow through the rest of the thought process, there is no need for a PR at all, and so no need to discuss it.

There's no reason to assume that a PR is required just because an issue was opened.

If we'd broken actual functionality in CPython or Cython, then there'd be a bug to consider. But all we broke is a misuse of a reserved field, and if it were in a single project then we wouldn't have spent anywhere near this amount of time discussing it - it's *only* because Cython was putting it in all its generated code that there's any reason to even look at this, as it could have a disproportionate effect if we believe it's a fair assumption that Cython-generated code targeting 3.7 should also work on 3.8. I've stated my opinion on that, but a decision either requires consensus from those of us involved here (Victor and Stefan) or an appeal to a higher authority (steering council).
msg345998 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-06-18 16:27
Steve Dower:
> * Pre-generated Cython .c files can be easily regenerated, and given their use of low-level and internal APIs would cause undue compatibility burden on CPython if we were to treat everything it uses as public stable API

It seems like you missed the whole point of this issue. No, it's not "easy" to regenerate these Cython .c files.

Let's pick a random module on PyPI... numpy.

$ python3.8 -m venv env
$ env/bin/python -m pip install numpy
...
Collecting numpy
  Downloading https://files.pythonhosted.org/packages/d3/4b/f9f4b96c0b1ba43d28a5bdc4b64f0b9d3fbcf31313a51bc766942866a7c7/numpy-1.16.4.zip (5.1MB)
...
    numpy/random/mtrand/mtrand.c:311:11: erreur: trop peu d'arguments pour la fonction « PyCode_New »
      311 |           PyCode_New(a, k, l, s, f, code, c, n, v, fv, cell, fn, name, fline, lnos)
          |           ^~~~~~~~~~


So right now, 16 days after Cython 0.29.10 release, numpy cannot be installed on Python 3.8 because of bpo-37221. But bpo-37221 is going to revert PyCode_New() API, and then the install will fail at "tp_print = NULL".

numpy is like one of the most popular C extensions on PyPI. But there are 184k projects on PyPI: some of them of Cython.

Some old projects on PyPI will never be updated anymore, but there are likely applications in applications which rely on them. This problem is very common.

Random example: setuptools is another top module on PyPI and it vendors html5lib. But html5lib didn't get a release for 1 year 1/2. html5lib emits a deprecation warning which now blocks bpo-37324 ("collections: remove deprecated aliases to ABC classes").

--

This issue is a practical problem: tons of projects on PyPI are currently broken on Python 3.8 and it will take *years* to update all of them.

IMHO we should reintroduce tp_print just to not break all these projects. 8 bytes per PyTypeObject is nothing compared to annoyance of issues introduced by tp_print removal.

--

Yes, I know that tp_print was deprecated for 10 years and it never emitted any deprecation warning. And people don't pay attention to warnings until it becomes a hard error...
msg346013 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2019-06-18 22:33
(Note: this isn't SC feedback yet, it's individual contributor feedback from me)

As others noted, the reason we treat "Incompatible with Cython generated source code" distinctly from other C API source compatibility issues is because Cython-using projects often add the generated files to their source tarballs, so install targets only need a C compiler, not Cython itself. Even when it's a case where the older Cython generated code wasn't doing the right thing, there's pragmatic value in smoothing those transitions.

That said, I still agree with PEP 590's decision to re-use the existing reserve function pointer slot, rather than adding a new one to the end of the type structure indefinitely, which would make the compatibility measure:

1. In 3.8.0b2, move tp_print to the end of the structure (rather than removing it entirely) to make the "type->tp_print" in the old Cython generated code harmless rather than a compilation error
2. In 3.9.0a1, remove it entirely again

That way we still end up in the place we were aiming to get in PEP 590, we just take an extra step in getting there.
History
Date User Action Args
2019-06-18 22:33:27ncoghlansetmessages: + msg346013
2019-06-18 16:27:40vstinnersetmessages: + msg345998
2019-06-18 16:12:31steve.dowersetmessages: + msg345996
2019-06-18 16:05:00jdemeyersetmessages: + msg345994
2019-06-18 15:55:12jdemeyersetmessages: + msg345992
2019-06-18 15:44:04steve.dowersetmessages: + msg345990
2019-06-18 15:22:43jdemeyersetmessages: + msg345989
2019-06-18 15:16:44steve.dowersetmessages: + msg345988
2019-06-18 09:07:26jdemeyersetmessages: + msg345969
2019-06-18 08:52:45vstinnersetmessages: + msg345966
2019-06-18 08:51:20jdemeyersettitle: C files generated by Cython set tp_print to NULL: PyTypeObject.tp_print removed, replaced with tp_vectorcall_offset -> C files generated by Cython set tp_print to 0: PyTypeObject.tp_print removed
2019-06-18 08:51:03jdemeyersetmessages: + msg345965
2019-06-18 08:50:26jdemeyersetpull_requests: + pull_request14030
2019-06-14 12:26:35scodersetmessages: + msg345591
2019-06-13 06:46:14jdemeyersetmessages: + msg345459
2019-06-12 21:18:33steve.dowersetmessages: + msg345409
2019-06-12 20:26:04scodersetmessages: + msg345405
2019-06-12 18:48:39scodersetmessages: + msg345402
2019-06-12 17:06:22steve.dowersetnosy: + ncoghlan
messages: + msg345383
2019-06-12 17:04:37steve.dowersetnosy: + steve.dower
messages: + msg345382
2019-06-12 14:00:18jdemeyersetmessages: + msg345359
2019-06-12 13:57:36jdemeyersetmessages: + msg345357
2019-06-12 13:47:35vstinnersetmessages: + msg345356
2019-06-12 13:41:43jdemeyersetmessages: + msg345355
2019-06-12 13:40:21jdemeyersetmessages: + msg345353
2019-06-12 13:39:49jdemeyersetmessages: + msg345352
2019-06-12 13:38:09vstinnersetmessages: + msg345351
2019-06-12 13:36:43vstinnersetmessages: + msg345350
2019-06-12 13:35:00jdemeyersetmessages: + msg345349
2019-06-12 13:32:33vstinnersetmessages: + msg345348
2019-06-12 13:31:05jdemeyersetmessages: + msg345347
2019-06-12 13:29:19vstinnersetmessages: + msg345346
2019-06-12 13:28:12vstinnersetmessages: + msg345345
2019-06-12 13:26:27vstinnersetnosy: + scoder, petr.viktorin
2019-06-12 13:24:33jdemeyersetmessages: + msg345344
2019-06-12 13:24:21vstinnersetmessages: + msg345343
2019-06-12 13:21:45vstinnersetmessages: + msg345342
2019-06-12 13:20:35jdemeyersetnosy: + jdemeyer
messages: + msg345341
2019-06-12 13:17:33vstinnersetmessages: + msg345340
2019-06-12 13:11:22vstinnersettitle: 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
2019-06-12 13:10:01jdemeyersetkeywords: + patch
stage: patch review
pull_requests: + pull_request13880
2019-06-12 13:08:30vstinnercreate