Fix issue 124

[jamadden]

There are three commits showing the iterations I went through.

• The first commit adds the necessary preprocessor magic to make the extension build and run on 3.9.0a3+.
• The second commit adds more preprocessor magic to make it build and run on 3.9.0a3 if Py_TRACE_REFS is actually defined.
• The third commit removes all usage of those internal functions entirely, after I verified that everything still worked on the Py_TRACE_REFS build.

Rationale to remove usage of the internal functions:

• They're documented specifically as only to be used by the core interpreter.
• The nesting of conditions to make them work was pretty ugly.
• Especially since the core logic of the function is already "hairy."
• It was not at all clear to me that they were actually doing the right thing anymore given the way the interpreter has evolved (e.g., with the separation of Py_REF_DEBUG and Py_TRACE_REFS); it's possible they could do more harm than good (I didn't observe any issues with just Py_TRACE_REFS, but I didn't test any more combos of settings)
• I think they were there to assist in debugging. But this function hasn't changed substantially in the history of this repository (9 years), so maybe it's debugged.

Fixes #124

[icemac]

I like it very much that you tackled this issue although I am not able to review it. Maybe it should be tested on Python 3.9 on TravisCI as well.

[icemac]

There is #123 where I ran the tests on Python 3.9 on Travis CI but they where green without the changes here. According to #124 this is because the pure Python version us used. Can we do something to force using the C version or at least check if it can be used to have a more clear indicator for changes in the C API in future?

[jamadden]

I ran the tests on Python 3.9 on Travis CI but they where green without the changes here. According to #124 this is because the pure Python version us used

In this case, it's because the breaking changes are not actually released yet. They are not in 3.9a3, only in git master. Everything compiles and runs fine (except for that one warning) on 3.9a3 still.

Can we do something to force using the C version

I think so. I like the way zope.interface is handling things (a decorator, plus a distinction between PURE_PYTHON=0 and PURE_PYTHON=1) and I'd like to spread that around.

[jamadden]

have a more clear indicator for changes in the C API in future?

We could also try setting CFLAGS=-Werror. That would have caught the PyEval_CallObject issue, but, since _Py_NewReference and friends are private, it wouldn't have caught that. Plus there's the possibility of false positives unless it's scoped very carefully.

[jamadden]

Because this is such a simple change that only affects specialized builds of Python, I'm tempted to merge it.